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Summary 
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The  first  phase  of  the  project,  creation  of  a 
preliminary  MSG  model,  is  complete.  This  report  is  a guide 
to  readers  of  the  model.  Section  1 gives  an  introduction 
the  experiment  and  to  MSG.  Section  2 is  an 
model,  discussing  its  internal  structure 
interfaces.  Communication  between  MSG 
processes  it  serves  is  described,  as  are  the 
buffering  algorithms  by  ;hich  interprocess 
delivered.  The  method  usea  to  encapsulate 


to 

overview  of  the 
and  external 
and  the  local 
sequencing  and 
messages  are 
the  detailed 


representations  of  network  protocol  items  is  presented,  and 
the  schemes  for  cleaning  up  MSG's  data  base  when 
transactions  time  out  or  are  rescinded  are  also  discussed. 
Finally,  section  3 of  the  report  provides  a guide  to  the 
language  in  which  the  model  is  written 


The  text  of  the  model  appears  in  the  appendix. 
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1 , Introduction 

experiment  in  program  development  end  evolution  i. 
under  »„  at  Center  tor  .ese.roh  in  Computing 

Technology ■ ...  P-P-  » « -*  l”t*"d"‘  “ 

reduce  tn,  ooet  end  enhance  tn,  neli.PiUt,  of  e.ftuer. 

maintenance . 

The  experiment  involves  the  implementation  of  a system 
of  moderate  size  and  complexity  that  has  been  designed  for 
the  Defense  Department  and  has  been  implemented  for  several 
h0St  computers  by  conventional  means.  The  exemplary  system 

is  thus  actually  a family.  of  pr°6ramS  sharlRg 

..  . . „ but  having  a number  of  markedly  different 

specification  but  navm& 

implementations . 

Such  families  occur  quite  frequently.  Operating 

systems  tnat  must  provide  similar  environments  on  different 
physical  configurations,  communications  processors  that  must 
observe  a common  protocol  while  running  on  a variety  of  host 

machines,  and  compilers  of  the  same  programming  language  for 

. __  be  regarded  as  comprising 

different  target  computers  c . 

families . 

Our  experiment  deal,  particular!,  -ltd  the  cre.ticr  and 

of  such  program  families,  although  the 

maintenance  of  sucn  pr  & 

or'f  i vp  in  developing 

techniques  we  employ  are 

single-instance  systems  as  well.  Our  aim  is  « *»»  « 

concentrating  fro.  the  cutset  on  the  development  of  a Tamil, 
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of  programs,  designers  can  dramatically  reduce  the  costs  of 
producing  a new  member  of  the  family  and  of  maintaining  its 
members  in  unison. 

1 . 1 The  Exemplary  System : MSG 

The  specific  program  we  are  experimenting  with,  called 
MSG,  is  the  interprocess  communications  handler  for  the 
National  Software  Works  (NSW)  [Spec].  The  NSW  is  a 
distributed  operating  system  now  being  developed  for  the 
ARPA  network  It  provides  users  of  the  ARPANET  with  a 
uniform  means  of  accessing  the  tools  and  dat3  bases  of  the 
network  without  having  to  know  where  they  reside  or  how  to 
deal  with  the  id iosyncrac ies  of  individual  tool-bearing 
hosts . 


An  instance  of  MSG  runs  on  each  host  participating  in 
the  NSW.  In  effect,  it  extends  the  local  host  operating 
system.  It  is  responsible  for  starting  and  managing  the 
processes  which  implement  various  NSW  functions,  such  as  the 
Works  Manager,  which  assigns  tasks  to  tool  bearing  hosts, 
the  File  Package  which  implements  a distributed  filing 
system,  the  Front  End,  which  provides  users  with  a uniform 
interface  to  the  NSW,  and  the  Foremen,  which  supervise  the 
various  tools. 

MSG  routes  messages  between  NSW  processes,  and,  when 
necessary,  establishes  direct  network  connections  between 
them.  Messages  may  be  either  gener ically  or  specifically 
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addressed.  A generically  addressed  message  causes  MSG  to 
seek  or  create  a process  of  a particular  class  (e.g.,  Works 
Manager).  Specifically  addressed  messages  are  routed  by  MSG 
to  a precisely  designated  destination  process.  They  are 
normally  used  after  communication  has  been  established  using 
a generically  addressed  message. 

MSG  provides  facilities  for  ordering  messages  and 
synchronizing  message  streams  with  respect  to  unusual  events 
or  exceptions.  Normally,  MSG  does  not  guarantee  that 
messages  will  be  delivered  in  the  order  submitted.  The 
sending  process,  however,  may  specify  that  a subset  of  its 
messages  to  a given  destination  must  be  delivered  in  the 
sequence  sent,  and  that  such  sequenced  messages  must  not  be 
sent  if  earlier  members  of  the  sequence  were  not  deliverable 
for  some  reason. 

To  permit  interprocess  signalling  of  exceptional 
events,  MSG  provides  for  high  priority  transmission  of  short 
communications,  called  alarms . Alarms  are  handled 
independently  of  any  message  traffic  between  the  sending  and 
receiving  processes.  They  can  be  used  to  facilitate 
resynchronization  of  a message  interchange. 

To  aid  synchronization  of  messages  with  alarms,  MSG 
permits  certain  messages  to  be  stream-marked . A 
stream-marked  m ^sage  will  be  delivered  after  any  prior 
messages  to  the  same  destination  and  before  all  those  sent 
subsequently . 
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Instances  of  MSG  on  different  hosts  communicate  using  a 
protocol  that  provides  for  the  establishment  and  termination 
of  MSG-to-MSG  network  connections  and  for  all  three  types  of 
communication  supported  by  MSG:  messages,  alarms,  and 
direct  connections  between  processes.  The  message  protocol 
includes  items  that  facilitate  flow  control  so  that  the 
burden  of  buffering  messages  can  be  distributed  between 
sender  and  receiver  when  traffic  is  heavy. 

Further  details  on  the  functions  performed  by  MSG  and 
on  the  MSG-to-MSG  protocol  can  be  found  in  the  MSG  Design 
Specification  [Spec].  A familiarity  with  the  specification 
will  be  assumed  in  section  ? of  this  report. 

1.2  Method  o_f  Develo pmen t and  Evolution 

Our  hypothesis  is  that  program  maintenance  can  be  made 

less  costly  and  mo, e dependable  if  system  designers  view 

their  task  as  the  design  of  a program  family  whose  members 
are  derived  from  a common  ancestor,  or  root,  which  we  call 
the  abstract  model  for  the  family.  Use  of  the  term 
"abstract-  is  not  intended  to  imply  that  the  model  is  a 
formal  mathematical  object.  Rather  it  is  a program  written 
with  sufficient  generality  that  members  of  the  family  can  ue 
obtained  by  specialization  of  it. 

Concrete  program  instances  are  derived  by  a sequence  of 
refinements  from  the  abstract  model.  Each  refinement 
encapsulates  related  design  decisions  that  distinguish  a 
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class  of  concrete  instances.  A refinement  may  jiva 
definition  to  a procedure,  a data  structure,  or  a control 
pattern  left  unbound  at  the  abstract  level,  or  it  may  modify 
or  augment  such  constructs.  The  program  family  thus  forms  a 
tree,  with  the  abstract  model  at  the  root,  the  co.vrete 
instances  at  the  leaves,  particular  refinements  lailing 
branches,  and  interior  nodes  that  represent  classes  of 
instances  sharing  a common  set  of  refinement  choices. 

We  have  developed,  and  are  constantly  improving,  tools 
that  aid  developers  by  maintaining  the  family  tree  m a data 
base  and  by  mechanizing  the  tasK  of  applying  refinement 
sequences.  Using  these  tools,  a new  member  of  an.  existing 
family  is  less  expensive  to  produce  than  one  developed 
separately  because  the  basic  model  and  most  of  the 
refinements  that  yield  the  new  version  will  be  shared  with 
existing  instances.  Moreover,  modifications  to  broad 
subfamilies  can  be  effected  in  unison,  by  applying  altered 

..  v fhaf  reflect  revised  design  decisions  and  simply 

refinements  that  retiecu 

reapplying  those  not  affected. 

Our  techniques  are  not  restricted  to  programs  like  MSG 
that  must  exist  in  many  functionally  similar  but  internally 
disparate  versions  at  the  same  time.  The  history  of  every 
evolving  program  is  a senes  of  closely  r.ia 
which  themselves  comprise  a family.  The  clear  isolation  of 
the  individual  design  decisions  leading  to  a particular 
instance  presents  the  maintainer  with  a picture  of  its 
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structure  that  enables  him  to  understand  the  ramifications 
of  a particular  modification  better  than  can  a single-level 
representation  of  a system. 

This  approach  is  particularly  beneficial  if  the 
software  engineer  charged  with  modifying  or  expanding  a 
system  has  not  been  involved  in  its  prior  development. 
Instead  of  confronting  a finished  product  together  with  some 
documentation  about  what  it  does,  he  has  access  to 
information  about  how  it  was  constructed,  why  particular 
decisions  were  taken,  and  what  the  effects  of  changing  them 
would  be.  He  has  tools  that  permit  him  to  take  the  program 
apart  and  reconstruct  it  easily,  to  generate  a new  version 
or  to  revert  quickly  to  an  old  one. 

In  short,  with  these  techniques,  the  roles  of  initial 
developer  and  maintair.er  tend  to  merge.  The  maintair.er  can 
afford  to  leave  the  system  in  as  clean  and  well-structured  a 
state  as  its  originators,  even  after  several  stages  of 
evolution.  By  contrast,  systems  developed  by  conventional 
methods  often  reach  an  overmaintained  state  after  a few 
successive  versions  have  been  produced.  After  this  point, 
the  quality  of  each  version  may  well  deteriorate  rather  than 
improve  [Belady]. 

Another  aspect  of  software  construction  that  fits 
naturally  into  the  family  maintenance  framework  is  the  use 
of  library  procedures  and  data  abstra-ct ions . An  implementer 
often  needs  to  take  a general  algorithm  or  data  definition, 
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with  known  properties  of  correctness  and  performance,  and 
specialize  it  to  a particular  task,  with  particular  physical 
data  representations.  Sometimes  many  distinct  realizations 
of  the  same  abstract  notion  will  be  used  in  a single  system. 
The  specialized  versions  of  such  library  modules  also 
constitute  a family  whose  members  can  be  produced  and 
maintained  using  the  tools  we  are  developing. 

1 . 3 Reaso,  s for  Choosing  MSG 

The  MSG  paradigm  is  a good  basis  for  our  experiment 
because  it  is  a family  of  communicating  programs  and  because 
teresting  maintenance  requ iremen ts , drawn  from  experience 
with  the  NSk  can  be  anticipated  in  the  near  future. 

Instances  of  MSG  should  appear  to  function  identically 
in  spite  of  highly  dispai ate  host  systems.  Since  they  must 
communicate  effectively,  the  behavior  of  each  must  be 
closely  coupled  to  that  of  the  others.  When  one  MSG 
instance  is  altered  in  an  externally  observable  way,  all 
should  be  alt  red  in  unison. 

The  MSG-to-MSG  protocol  is  relatively  simple,  but  the 
operating  environment  is  imperfect.  Host:.  may  die,  or  pause 
indefinitely;  processes  may  also  die,  or  they  may  change 
their  minds;  interhost  connections  may  drop.  These 
possibilities  introduce  complexities  in  interhost  MSG 
communication  which  are  virtually  impossible  to  capture  in  a 
nonprocedural  English,  item-by-item  protocol  specification. 
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Such  a specification,  indeed,  is  aimed  at  minimizing  the 
description  of  external  behavior  in  order  to  give  maximum 
flexibility  to  implementers  and  maintainers  of  individual 
instances.  Unfortunately,  the  use  of  imprecise  interface 
specifications  when  interfaces  are  potentially  complex  can 
lead  to  inefficient,  defensive  strategies,  or  much  worse,  to 
inconsistent  inter pretat ions  by  different  implementers. 

Our  view  is  that  each  instance  of  MSG  should  be 
constructed  as  if  it  were  to  communicate  with  an  exact 
replica  of  itself.  The  abstract  model  of  MSG  thus  provides 
a precise  description  of  the  behavior  of  any  instance  in  any 
circumstance,  and  this  knowledge  can  be  used  in  realizing 
anv  concrete  version.  Ti.ere  is  no  harm  in  this  mutual 
knowledge  because  the  family  members  are  maintained  in 
unison.  Useful  flexibility,  that  needed  to  accomodate 
differences  in  host  facilities  and  resources,  results  from 
the  abstractness  of  the  model. 


1.1J  Phase  One : The  Abstract  Model 


During 

the  first  phase 

of 

the 

project,  we  have 

constructed 

an  abstract  model 

of 

MSG. 

In  later  phases,  we 

plan  to  ref 

ine  the  model  to 

two 

concrete  instances  on 

dissimilar 

target  machines, 

the 

DEC 

PDP-10  and  PDP-11, 

running  the  TENEX  and  UNIX  operating  systems,  respectively. 
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The  remaining  sections  of  this  report  are  intended  as  a 
guide  to  readers  of  the  model,  which  appears  in  the 
appendix.  Section  2 provides  an  overview  of  the  model 
itself.  It  assumes  some  familiarity  with  the  MSG  Design 
Specification.  Section  j describes  the  modelling  language 
and  highlights  some  of  the  features  we  use  to  aid  both  the 
readability  and  refinability  of  abstract  algorithms. 


Abstract  Model  of  MS 0 


11 

2.  Guide  to  the  MSG  Mode  1 
2.1  An  Overview 

MSG  instances  on  each  of  the  participating  hosts  link 
the  NSW  together  by  carrying  out  communication  between  the 
processes  that  comprise  it,  as  depicted  in  figure  1.  The 
double  shafted  arrows  in  this  picture  represent  channels  for 
interprocess  communication.  Those  linking  processes  on 
different  hosts  will  be  implemented  using  network 
connections.  Those  between  processes  on  the  same  host  will 
be  realized  using  whatever  interprocess  communication  (IPC) 
facility  is  most  suitable  on  that  host.  Some  hosts,  such  as 
CCN  (360/91),  offer  an  IPC  facility  that  closely  resembles 
the  channel  abstraction  we  have  used  in  modelling  MSG.  On 
others,  such  as  TENEX,  direct  communication  via  shared 
memory  may  be  best.  We  neither  assume  nor  prohibit 
hierarchical  relationships  between  MSG  and  the  processes  it 
serves.  Depending  on  the  host  operating  system  (if  any),  it 
may  be  useful  to  organize  processes  hierarchically  in  order 
to  achieve  the  most  effective  IPC. 

In  our  model,  each  MSG  instance  is  structured  as  a 
collection  of  paths  serving  specialized  functions  and 
sharing  a common  data  base . Paths,  like  processes,  are 
potentially  concurrently  executable  control  units.  We 
distinguish  ’'path”  from  "process”  to  emphasize  that  paths 
internal  to  MSG  may  or  may  not  be  implemented  using  the 
process  management  facilities  of  the  host  operating  system. 
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For  each  transaction  that  MSG  processes, 
message  and  alarm  sent  or  received  and 
connection  established,  the  data  base 
describing  the  state  of  the  transaction. 


that  is , for  each 
for  each  direct 
holds  a record 


The  modules  that  comprise  the  MSG  model  are:  LOCAL, 
which  defines  the  interface  between  MSG  and  local  processes, 
REMOTE,  which  contains  the  network  interface,  QUEUE,  which 
includes  routing  algorithms  and  data  base  management 
routines,  CANCEL,  which  expunges  transactions  that,  for  one 
reason  or  another,  cannot  be  completed,  and  DRIVER,  which  is 
responsible  for  initialization  of  MSG  and  of  local 
processes.  Another  module,  GLOBAL,  collects  the  common, 
(among  modules)  data  definitions  for  the  model.  Finally, 
PROCESS  is  a small  module  that  contains  the  routines  that 
must  be  embedded  in  processes  for  use  in  initiating  MSG 
primitive  operations. 


Within  MSG  there  is  a server  pair 
process.  A server  pair  is  a pair  of  path 
functions  correspond  roughly,  though  not  exa 
and  output.  In  the  case  of  a process  server 
correspond  to  the  two  phases  of  many 
operations.  The  first  is  the  call  pha 

accepts  and  validates  arguments.  If  the  cal 
the  process  is  allowed  to  continue  exe 
proceeds  with  its  request.  When  the 
complete,  the  second,  or  delivery  phase 


for  each  user 
s whose  separate 
ctly,  to  input 
, the  two  halves 
MSG  primitive 
se,  in  which  MSG 
1 is  acceptable, 
cution  while  MSG 
transaction  is 
of  the  primitive 
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operation  occurs,  in  which  the  disposition  of  the 
transaction  is  transmitted  to  the  process,  along  with  any 
incoming  information,  such  as  message  text,  an  alarm  code, 
or  a network  connection  designator.  Primitive  operations 
that  occur  in  two  stages  this  way  are  said  to  create  pending 
events  for  later  completion. 

The  model  does  not  fix  the  number  of  user  processes 
assigned  to  a given  server  pair.  There  may  be  one  pair  per 
process,  one  per  generic  class,  one  for  all  processes,  or 
some  other  configuration  if  convenient.  If  there  are 
multiple  server  pairs,  each  is  identical  in  operation  to  the 
next.  They  share  the  procedures  given  in  module  LOCAL. 

Symmetrical  with  the  set  of  user  process  servers  is 
another  set  of  server  pairs  called  network  servers.  A 
network  server  implements  the  inter-MSG  protocol  by 
formatting  and  transmitting  protocol  items  from  the  local 
MSG  to  instances  of  MSG  on  other  hosts,  and  receiving  items 
from  other  hosts  and  translating  them  into  internal  MSG 
records.  In  a given  realization  of  MSG,  each  network  pair 
may  handle  a single  remote  host  or  several  of  them.  Like 
the  local  process  servers,  each  network  server  is  identical 
with  the  next.  All  share  the  algorithms  given  in  module 
REMOTE  of  the  model. 

The  paths  labelled  ICP  and  Auth  in  figure  1 are  also 
defined  in  the  module  REMOTE.  They  take  part  in  the 


establishment  of  connections  with  remote  hosts.  ICP  (which 
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stands  for  Initial  Connection  Protocol)  is  activated  when 
another  host  initiates  a connection  with  the  local  MSG. 
Auth  is  used  in  authenticating  the  identity  of  the  local  MSG 
when  it  has  initiated  a connection  with  an  MSG  instance  on 
another  host. 

Timer  is  MSG’s  clock-watching  path.  For  most  of  the 
states  in  which  a transaction  car.  be,  it  is  desirable  that  a 
limit  be  enforced  on  the  amount  of  time  allowed  to  elapse 
without  some  progress  being  made.  Time  limits  are  specified 
when  a user  process  issues  a primitive  call,  and  they  are 
also  set  in  certain  states  by  MSG  in  order  to  implement  its 
flow  control  policies.  The  Timer  path,  defined  in  the 
module  CANCEL,  manages  a queue  of  transactions  sorted  in 
order  of  their  expiration  times.  It  uses  a real  time  clock 
interrupt  to  generate  timeout  signals,  and  it  responds  to 
them  by  aborting  expired  transactions  and  expunging  their 
records  from  the  system.  The  intent  is  that,  given  a long 
enough  quiescent  period  with  no  incoming  or  outgoing 
transmissions,  MSG  will  tend  to  return  to  its  initial  state. 
(There  are  exceptions  to  this  rule,  however.  Direct 
connections  to  other  hosts,  for  instance,  do  not  expire 
whether  or  not  they  are  used.) 

The  remaining  internal  path  shown  in  figure  1,  called 
Driver,  is  the  first  to  be  executed  when  an  MSG  instance  is 
executed.  It  performs  initialization  tasks,  including  the 
creation  of  local  processes  and  server  paths.  In  some 
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realizations  of  MSG,  the  Driver  may  be  a superior  of  the 
.paths  comprising  MSG,  and  indeed  may  act  as  a scheduler  for 
them.  These  details  are  omitted  from  the  abstract  DRIVER 
module,  however,  since  they  depend  critically  on  the  nature 
of  the  underlying  host's  facilities. 

The  single -shafted  arrows  in  figure  1 denote  direct 
communication  among  internal  MSG  processes  via  a shared  data 
base  containing  records  for  each  transaction  known  to  the 
system  at  any  moment.  The  routines  that  manage  this  data 
base  are  contained  in  the  MSG  modules  called  QUEUE  and 
CANCEL.  The  data  base  manager  is  not  a separate  path. 
Rather,  the  routines  in  QUEUE  and  CANCEL  are  called  by  the 
internal  paths  of  MSG  to  access  and  alter  the  data  base  in 
response  to  particular  stimuli  such  as  the  arrival  of  a 
protocol  item  on  the  network,  the  execution  of  a user 
primitive,  or  the  expiration  of  a time  limit  for  some 
transaction.  QUEUE  is  so  named  because  its  primary  task  is 
to  enqueue  items  for  output  over  the  network  or  for  delivery 
to  local  processes.  CANCEL  contains  routines  to  discard 
incomplete  transactions  when  they  must  be  aborted. 

The  data  base  is  composed  mainly  of  transaction  records 
defined  by  the  data  types  MessBlock,  AlarmBlock,  and 
ConnBlock,  one  for  each  of  the  three  modes  of  communication 
supported  by  MSG.  These  types  are  defined  in  the  module 
GLOBAL.  To  emphasize  the  fact  that  these  records  are  shared 
among  multiple  paths  and  are  accessible  via  several  routes 
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at  once  in  the  data  base,  the  model  usually  manipulates 
"handles"  on  records.  The  data  type  MessHandle,  for 
instance,  has  the  abstract  behavior  of  a pointer  to  a 
MessBlock  (though  it  need  not  be  realized  as  a pointer  in 
concrete  versions  of  MSG).  Collections  of  message  records 
are  expressed  as  sets  or  queues  of  MessHar.dles. 

The  anchor  points  from  which  most  records  in  the  data 
base  are  accessed  are  the  data  structures  ProcessTable , 
Server  Table  , Hosts,  Tr  ansae  tionTable  , Gen.er  icTable , and 
TimerQ.  ProcessTable  maps  process  names  (and,  in 
particular,  the  process  instance  identifiers  within  process 
names)  to  ProcessHandles . Every  local  process  managed  by 
MSG  has  a Process  Hand le  in  ProcessTable.  The  data 
accessible  through  a ProcessHar.d  le  (see  module  GLOBAL  for 
all  global  data  types)  give  the  state  of  MSG  * s interaction 
with  the  process,  including  the  pending  primitives  waiting 
to  be  completed,  incoming  messages  and  alarms  waiting  for 
delivery,  and  direct  network  connections  to  other  processes. 

ServerTable  contains  a record  for  each  of  i"he  process 
server  and  network  server  pairs  internal  to  MSG.  This  is, 
in  general,  a dynamically  varying  collection,  since  there 
might  be  a server  pair  for  each  active  user  process  and 
remote  host  connection.  An  important  component  of  the 
record  for  each  server  is  its  delivery  queue,  which  is 
filled  with  transaction  records  produced  by  other  paths  and 
emptied  by  the  server  as  the  items  are  attended  to.  The 
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delivery  queue  of  a local  process  server  holds  the  pending 
events  ready  to  be  completed.  That  of  a network  server 
contains  protocol  items  awaiting  transmission. 

Hosts  includes  an  entry  for  each  remote  host  with  which 
MSG  has  established  contact.  Among  other  fields,  the  remote 
host  entry  holds  the  incarnation  number  of  the  MSG  instance 
running  on  the  remote  host,  and  a set  of  Channe 1 Hand les  that 
describe  the  connections  currently  open  to  that  host  for  use 
by  MSG. 

Since  some  transactions  handled  by  MSG  involve  the 
exchange  of  several  protocol  items,  it  is  convenient  to  have 
each  MSG  instance  assign  a unique  identifier  to  the 
transactions  in  which  it  is  involved.  Transact ior.Table  is 
used  in  the  assignment  of  these  identifiers,  which  are 
designed  to  repeat  very  infrequently.  It  also  gives  quick 
access  to  the  data  base  record  for  any  transaction,  given 
its  transaction  identifier  as  a key. 

GenericTable  has  an  entry  for  each  generic  process 
class,  such  as  Works  Manage'"  or  File  Package.  It  contains 
records  needed  to  start  a new  process  of  a given  class,  and 
it  indicates  which  NSW  hosts  support  each  generic  class,  so 
that  an  outgoing  generically  addressed  message  can  be 
routed.  GenericTable  also  contains  holding  places  for 
incoming  generic  messages  when  it  is  not  possible  to  assign 
them  immediately  to  specific  processes  of  the  proper  class. 
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TimerQ  is  the  queue  of  transactions  being  timed  by 
Timer,  sorted  in  order  of  expiration  time. 

Of  course,  with  multiple  parallel  paths  accessing  and 
altering  shared  records,  it  is  necessary  to  employ  a record 
locking  mechanism  to  guarantee  orderly  sequential  access. 
This  mechanism  is  invoked  in  the  model  through  the 
primitives  Seize,  TestSeize,  and  Release.  Seize  blocks  the 
calling  process  until  exclusive  access  can  be  granted  to  the 
caller.  Release  unlocks  a previously  seized  resource. 
TestSeize  attempts  to  seize  a resource,  but  does  not  block 
if  it  is  unsuccessful.  Instead,  it  returns  a Boolean  value 
indicating  success  or  failure. 

Although  these  primitives  are  used  in  the  MSG  model,  so 
that  it  can  be  checked  for  errors  such  as  deadlock,  the 
implementations  of  Seize,  TestSeize,  and  Release  are 
deliberately  left  unspecified.  In  some  purely  sequential 
realizations,  there  will  be  no  need  for  locks  and  these 
primitives  can  be  refined  away. 

Storage  management  of  records  presents  a similar 
situation.  The  routine  Allocate  is  used  to  enter  new 
records  in  the  data  base,  and  Free  is  used  to  indicate  that 
one  reference  to  a record  has  been  deleted.  However,  the 
record  may  only  be  reclaimed  when  all  such  references  have 
been  eliminated.  If  Free  cannot  safely  reclaim  storage,  it 
simply  performs  a Release.  The  detailed  mechanisms  for 
ensuring  that  storage  can  be  reclaimed  safely  are  deferred 
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to  a lower  level  of  refinement. 


2.2  The 

Inter  f ace 

Between 

MSG 

sr. d Local  Processes 

The 

modules 

PROCESS 

and 

LOCAL  model  the  interface 

between 

MSG  and 

the  local 

processes  it  serves.  PROCESS 

contains 

routines 

to  be 

loaded  with  user  processes  and 

called  by  them  to  initiate  MSG  primitives.  These  routines 
are  quite  simple;  they  merely  transmit  arguments  to  MSG  and 
guide  results  into  place.  LOCAL  contains  the  procedures  and 

tables  used  by  each  pair  of  server  paths  which  implement  the 
primitive  operations. 

2.2.1  Communication  Between  MSG  and  Local  Processes 

In  the  abstract  MSG  model,  processes  communicate  with 
MSG  by  way  of  signals  and  channels.  The  particular 
mechanisms  used  were  chosen  to  make  the  model  as  simple  as 

possible  within  the  constraint  that  they  must  be  realizable 
in  a variety  of  host  systems. 

A .?JgRaA  is  a da  ta  less  communication  between  two 
processes  used  to  herald  events  and  achieve  synchronization. 
In  MSG,  signal  identifiers  of  type  Sign.alType  are  used  to 
distinguish  among  the  several  signals  with  different 
meanings  that  may  be  in  use  between  two  processes.  The 
expression  SIGNAL(<signal  identifier))  sends  the  designated 
signal.  WAIT«signal  set>)  blocks  the  calling  process  until 
a member  of  the  designated  set  of  signals  is  received.  Tt 
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returns  the  identifier  of  that  signal  as  its  result. 

A channel  is  opened  between  two  processes  when  each 
calls  CHOPEN  with  the  same  channel  identifier  and  compatible 
channel  descriptors.  SEND(<data  list>,  <chanr.el>)  is  used 
to  send  a group  of  data  over  a channel.  SEND  always  blocks 
the  calling  process  until  the  data  have  been  received. 
RECEIVE ( Cvariable  list>,  <channel>,  Cblock  flag>)  fills  the 
elements  of  a list  of  variables  by  reading  from  a channel. 
RECEIVE's  third  argument  is  a Boolean  which,  when  TRUE, 
causes  the  calling  process  to  block  until  the  whole  variable 
list  has  been  read.  If  this  argument  is  FALSE,  the  caller 
may  proceed  while  the  data  are  being  read.  Presumably,  in 
the  latter  case,  the  caller  has  another  way  of  knowing  when 
the  transmission  is  complete.  For  example,  the  sender  may 
use  a signal  to  alert  the  receiver. 

A channel  may  be  closed  from  either  side  using  the 
CHCLOSE  operator,  but  it  will  be  closed  only  after  data  in 
the  channel  have  been  received. 

CHOPEN,  CHCLOSE,  SEND,  and  RECEIVE  are  specified  in 
module  GLOBAL. 

PROCESS  and  LOCAL  use  a few  notational  extensions  for 
dealing  with  channels.  The  expression  < X 1 , ...,  Xk>  = ! > CH 
is  equivalent  to  SEND(<X1,  ...,  Xk>,  CH),  which  sends  the 
successive  values  XI  though  Xk  over  channel  CH.  Similarly, 
<V1,  ...,  Vk>  <!=  CH  stands  for  a non-blocking  RECEIVE  call: 
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REUIVEUVI,  Vk>,  CH,  FALSE) 

while  < , ...»  Vk>  < ! ! = CH  stands  for  a blocking  RECEIVE: 

RE'.::iVE(<V1,  Vk>,  CH,  TRUE). 

Also,  <F1,  F n > ( M ) is  equivalent  to  <M.F1,  M.Fn>. 

2.2.2  Primitive  Routines  Within  User  Processes 

Module  PROCESS  contains  a routine  definition  for  each 
primitive  defined  in  the  MSG  specification.  Each  consists 
of  a call  on  one  general  routire,  PCall.  PCall  has  four 
arguments:  Op  identifies  the  particular  primitive  being 

invoked;  SendList  is  the  list  of  data  that  must  be  sent  to 
MSG  to  allow  it  to  execute  vhe  operation;  ReceiveList  is  a 
list  of  variables  to  be  filled  by  the  time  the  primitive 
completes;  and  Creates  Pend ing Even t is  bound  to  TRUE  for 
those  primitives  that  occur  in  two  stages,  i.e.,  that  create 
pending  events.  In  addition,  PCall  sets  the  variable 
Pen d ing Ev on t I D , which  is  an  output  parameter  of  every 
pending  event  creating  primitive  routine. 

As  an  example,  the  body  of  the  Rece iveSpeci f icMessage 
primitive  is: 

PC al  1 ( ” Receive Specific Me ssage”  „ 

<Signal,  Timer>, 

<Text,  SourcePrccess , Handling,  Dispos ition> , 

TRUE) 

Here  Signal  represents  the  signal  identifier  chosen  by  the 
calling  process  for  MSG's  use  in  signalling  completion  of 
the  Receive.  By  convention,  a special  value  of  Sigr.alType 
can  be  usea  if  the  caller  wishes  the  primitive  to  block 
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until  completion  instead  of  returning  while  the  transaction 
proceeds.  Timer  is  the  maximum  delay  the  calling  process 
will  allow  before  satisfaction  of  the  Receive  request. 
Text,  Source  Process , Handling,  and  Disposition  are  the 
output  variables  into  which  the  results  of  the  Receive  are 
to  be  placed.  Text  will  hold  the  actual  message; 
SourceProcess  will  be  the  name  of  the  sending  process, 
Handling  will  indicate  what  special  handling  the  message  may 
have,  and  Disposition  is  a code  that  indicates  whether  the 
operation  succeeded  or  failed,  ard  if  it  failed,  then  why. 

Every  process  has  a channel,  called  MSGChannel, 
permanently  open  to  MSG . It  is  used  fo>'  those  primitives 
that  do  not  create  pending  events  and  f^r  trie  call  phase  of 
those  that  do.  PCall  uses  MSGChannel  to  send  the  identifier 
Op  and  the  SendList  parameters  to  MSG,  and  then  waits  for 
its  reply  on  the  same  channel.  MSG  answers  with  a 
disposition  code.  If  this  code  indicates  some  error,  PCall 
terminates  the  primitive  by  returning  the  error  code.  If 
MSGfs  reply  is  normal,  and  the  primitive  does  not  create  a 
pending  event,  then  the  rest  of  the  data  for  the  ReceiveList 
come  over  MSGChannel,  and  the  primitive  returns  an 
indication  of  normal  completion. 

For  pending  event  primitives  that  get  past  initial 
validation.  MSG  sends  back  an  identifier  which  will  be 
uniquely  associated  with  the  current  transaction.  PCall 
assigns  this  identifier  to  Pend ingEvent ID.  It  can  be  used 
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by  the  calling  process  to  rescind  a pending  event  before  it 
has  completed. 

Pend ir.gEventID  is  also  used  to  open  a new  channel  to  be 
used  exclusively  for  the  completion  of  the  current 
primitive.  Then  PCall  issues  a RFCEIVE  for  the  ReceiveList. 
Depending  on  whether  the  caller  has  asked  to  block  until 
completion  or  to  be  allowed  to  run,  PCall  will  block  or 
return  immediately.  In  the  latter  case,  MSG  uses  the  given 
signal  to  alert  the  user  process  that  the  primitive  has 
completed . 

2.2.3  The  Local  Process  Servers 

The  other  side  of  the  PROCESS-LOCAL  interface  is 
encoded  in  the  server  pair  assigned  to  the  user  process. 
The  main  procedures  for  the  pair  of  paths  comprising  the 
server  are  User  Cal lServer  and  User DeliveryServer . These  in 
turn  select  procedures  for  handling  the  individual  MSG 
primitives.  All  of  these  procedures  are  contained  in  module 
LOCAL. 

The  handling  of  a SendSpeci f icMessage  is  typical  of  how 
the  server  pair  deals  with  pending  event  primitives. 
UserCal lServer  monitors  the  permanent  channels  to  the 
processes  it  is  responsible  for.  When  it  receives  an 
operation  code  over  one  of  these  channels,  it  dispatches  to 
the  appropriate  handler,  as  given  by  Op Table.  The  handler 
is  given  the  Opcode  (since  the  same  handler  may  implement 
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more  than  one  primitive),  the  channel  to  the  local  process, 
and  a ProcessHandle  for  the  process.  In  the  case  of  a 
SendSpecif  icMessage  , User  CallServer  calls  StartSer.dMessage . 

Star  tSer.dMessage  receives  the  parameters  sent  by  the 
user  process  and  validates  them.  If  it  finds  an  error  it 
aborts  the  primitive  right  away,  sending  an  error  code  to 
the  process.  Otherwise,  it  indicates  that  the  call  phase 
will  complete  normally  by  sending  the  code  M Incomplete" . It 
assigns  a transaction  identifier  and  sends  it  to  the  user 
process,  and  it  uses  this  identifier  to  open  a new  channel 
for  completion  of  the  event.  Finally,  a transaction  record 
is  created  for  the  message  and  is  passed  to  Er.QOu tputMess , 
one  of  the  routines  exported  by  QUEUE. 

Eventually,  the  transaction  will  be  placed  in  the 
delivery  queue  of  the  server  and  will  be  found  there  by  the 
User  Deliver yServer . This  path  uses  the  original  operation 
code  to  dispatch  to  a handler  for  the  delivery  phase.  In 
the  case  of  SendSpeci f icMessage , the  delivery  handler  is 
EndSer.dMessage . End  Send  Message  finds  the  channel  opened  for 
this  transaction  and  sends  the  disposition  code  (the  only 
output  value  in  this  case)  to  the  process.  It  then  uses  the 
signal  supplied  by  the  process  to  signal  completion  of  the 
event,  and  it  frees  the  transaction  record  for  the  message. 
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2. 3 Message  Rout  in g and  Data  Base  Management 

As  mentioned  in  the  overview,  the  modules  QUEUE  and 
CANCEL  contain  routines  that  respond  to  events  which  drive 
MSG:  execution  of  primitives,  receipt  of  protocol  items, 

timeout  of  events,  and  so  on.  In  particular,  QUEUE  embodies 
most  of  MSG’s  routing  and  buffering  algorithms:  finding  a 

specific  destination  for  generically  addressed  messages, 
deciding  whether  to  buffer  or  reject  messages  that  cannot  be 
delivered  immediately,  sequencing  the  transmission  of 
’’special  handling”  messages,  and  the  like.  This  section 
summarizes  QUEUE’S  algorithms  for  each  class  of 

communication  supported  by  MSG.  The  next  section  discusses 
the  CANCEL  module. 

2.3.1  Message  Handling 
2.3.  1.1  Outgoing  Messages 

Figure  2 is  a state  transition  diagram  for  an  outgoing 
message.  The  initial  state  is  labelled  ”No  MESS  pending”. 


Arcs  representing 

transitions 

have 

labels  of 

the 

form 

Stimulus/ Response. 

Here  ’’stimulus” 

describes 

the 

event 

giving  rise  to  the 

transition , 

and 

’’response” 

describes 

MSG’s  action  (if  any)  upon  entering  the  new  state. 
"SendMess/ser.d  MESS”  (transition  2),  for  example,  denotes 
the  execution  of  a SendGer.er icMessage  or  Ser.dSpeci f icMessage 
primitive  by  a local  process.  MSG’s  response  is  to  transmit 
a MESS  protocol  item  to  the  destination  and  place  the 


Abstract  Model  of  MSG 


25A 


2: 

3: 

4: 


5: 

6: 


MESS-OX/  -- 
MESS-REJ/  -- 

MESS-HOLD/send  MESS-CANCEL 
SendMess/ sen d MESS 
MESS-RE J/abort  SendMess 

Buffer  needed  or  Timeout/ send  MESS-CANCEL, 
abort  SendMess 
MESS-OK/comple te  SendMess 
MESS-REJ/abort  SendMess 
MESS-HOLD/send  MESS-CANCEL, 
abort  SendMess 
Timeout/abort  SendMess 
MESS-HOLD/send  HOLD-OX 
XMIT/re transmit  MESS 


Figure  2,  State  Transitions  for  Cutgoing  Messages 
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transaction  in  the  state  " Awaiting  MESS-OK" . At  the  sane 
time,  a MessHar.dle  representing  the  transaction  is  placed  in 
the  OutputMessQ  associated  with  the  the  sending  process. 
The  response  to  a MESS  item  can  be  acceptance  (MESS-OK), 
outright  rejection  (MESS-HEJ),  or  a request  to  hold  the 
message  until  the  receiving  MSG  can  ask  for  retransmission 
(MESS-HOLD).  If  the  source  MSG  decides  to  accept  the 
request  to  hold,  it  signifies  by  sending  HOLD-OK  and  places 
the  transaction  in  the  state  "Awaiting  XMIT"  (transition  5). 
Receipt  of  an  XMIT  protocol  item  will  stimulate 
retransmission  of  the  MESS  (transition  6),  or  the 
transaction  may  die  through  receipt  of  a rejection  or 
through  old  age  (transition  3). 

The  self-loop  from  the  "No  MESS  pending"  state 
(transition  1),  which  responds  to  a MESS-HOLD  for  a 
non-existent  transaction  by  sending  MESS-CANCEL,  is  the 
result  of  the  model's  handling  of  timeouts.  If  the 
transact  ions • s time  limit  expires  while  it  is  in  the 
"Awaiting  MESS-OK"  state  (transition  4),  no  MESS-CANCEL  is 
sent  to  indicate  that  the  message  has  been  aborted.  Thus, 
if  the  remote  MSG  later  shows  an  interest  in  continuing  the 
transaction,  it  is  necessary  to  cancel  it  explicitly. 

The  routines  in  QUEUE  that  implement  transitions  shown 
in  figure  2 are  EnQOu tputMess , RecordMESSXOK, 
RecordMESSXRE J , Recor dMESSXHOLD,  RecordXMIT. 
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2.3.  1.2  Incoming  Messages 

Figure  3 shows  what  happens  at  the  receiving  end  of  a 
similar  transaction.  Here  the  initial  state  is  labelled 
’’Awaiting  MESS".  Ir.  this  state,  either  there  is  no 
transaction  pending  at  all,  or  a ReceiveMess  primitive  has 
preceded  the  arrival  of  a matching  MESS  item.  In  the  latter 
case,  a MessHandle  For  the  transaction  is  queued  in  the 
ReceiveMessQ  oF  the  receiving  process. 

When  a MESS  item  arrives,  it  may  be  accepted  outright 
(transitions  3 and  4 ) , or  rejected  outright  (transition  4), 
or  the  receiving  MSG  may  ask  the  sender  to  buFFer  the 
message  (transitions  1 cr  2).  Transition  3 is  taken  when  no 
matching  Rece  iveGer.er  icMessage  or  ReceiveSpeciFicMessage 
primitive  has  been  issued  by  a local  process.  Transition  1 
occurs  when  the  sending  MSG  has  oFFered  in  advance  to  buFFer 
the  message,  iF  necessary,  and  the  receiving  MSG  has 
accepted  the  invitation. 

When  there  is  some  delay  in  delivering  the  message,  its 
MessHandle  waits  in  the  Ir.putMessQ  oF  either  the  appropriate 
generic  class  (iF  the  message  is  generic)  or  the  destination 
process  (iF  it  is  speciFio)  until  it  can  be  disposed  oF.  In 
the  ’’Awaiting  ReceiveMess"  state,  either  a Receive  primitive 
is  executed  and  the  message  is  delivered,  or  the  time  limit 
placed  on  the  transaction  expires  and  the  MessHandle  is 
deleted  (transition  14). 
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1*  Mr3S ( uoldOk) /send  MESS-HOLD 
2:  MESS/ send  MESS-HOLD 
3:  MESS/send  MESS-OX 
4:  MESS/ send  MESS-OX, 

complete  ReceiveMess 
MESS/send  MESS-REJ 
HOLD-OX/send  XMIT 
MESS-CANCEL/  -- 
ReceiveMess/  -- 
5:  Buffer  free/send  XMIT 
6:  MESS-CANCEL/  -- 

Timeout/send  MESS-REJ 
7:  MESS-CANCEL/  -- 
Timeout/ 

8:  HOLD-OX/  -- 
9:  HOLD-OX/send  XMIT 
10:  MESS/send  MESS -OK, 

complete  ReceiveMess 
MESS/send  MESS-REJ 
MESS-CANCEL/  -- 
Timeout/  -- 

11:  MESS/send  MESS-HOLD 
12:  MESS ( Ho  Id  Ok) /send  MESS-HOLD 
13:  MESS/send  MESS-OX 
14:  Rece iveMess/complete  ReceiveMess 
Timeout/  -- 

Figure  3.  State  Transitions  for  Incoming  Messages 
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In  the  "Awaiting  HOLD-OK"  state,  a proper  stimulus  is 
either  MESS-CANCEL  or  HOLD-OK.  MESS-CANCEL  terminates  the 
transaction  (transition  7)  and  causes  its  necord  to  be 
deleted.  HOLD-OK  may  cause  MSG  either  to  send  an  XT-1  IT 
(transition  9),  if  buffer  space  for  the  message  has  become 
available,  or  simply  to  put  the  transaction  in  the  "Held  by 
sender"  state  (transition  8). 

Transactions  get  out  of  the  "Held  by  sender"  state 
either  because  the  sender  can  no  longer  afford  to  hold  a 
message  and  sends  MESS-CANCEL  (transition  6),  or  because 
sufficient  buffer  space  becomes  available  to  enable  MSG  to 
request  retransmission  of  the  message  by  sending  XMIT 
(transition  5).  The  state  "Awaiting  r etr an smissior. " is 
almost  equivalent  to  the  initial  state  "Awaiting  MESS"  since 
the  same  responses  are  possible  for  a retransmitted  message 
as  for  an  initial  message  (though  a request  to  re-hold  is 
unlikely).  One  point  of  difference  is  that  the  initial 
state  has  transitions  for  HOLD-OK  and  MESS-CANCEL 
(transition  4).  Like  the  initial  state  self-loop  in  figure 
2,  these  result  from  the  decision  not  to  flatly  terminate  a 
transaction  which  has  timed  out.  In  this  case,  if  a timeout 
occurs  in  the  state  "Awaiting  HOLD-OK"  (transition  7),  MSG 
deletes  the  transaction  without  sending  MESS-REJ.  If, 
later,  a HOLD-OK  arrives  for  that  transaction,  MSG  responds 
by  inviting  retransmission  (XMIT).  If  a MESS-CANCEL  comes 
in  for  a discarded  transaction,  it  is  just  ignored. 
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The  routines  that  implement  the  transitions  of  figure  3 
are  Er.QInpu  tMess  , Er QRece  iveMes s , Recor cMOLDNOK,  and 
Re co rdMESSX CANCEL. 

2.3.  1.3  Generically  Addressed  Messages 

An  aspect  of  MSG's  message  handling  procedures  not 
displayed  in  figures  2 and  3 is  its  treatment  of  generic 
messages.  On  output,  a generic  message  with  specific 
destination  host  is  treated  just  like  a specifically 
addressed  message.  If  no  host  is  specified,  however,  MSG 
must  choose  one  from  a list  of  hosts  supporting  the  chosen 
generic  category,  e.g.,  Works  Manager.  If  the  message  is 
not  accepted  by  the  first  host,  MSG  tries  the  others  in  the 
list  until  either  the  message  is  accepted  or  the  list  is 
exhausted.  To  implement  this  search,  MSG  (in  Er.QOu tpu tMess ) 
marks  such  a message  as  having  been  hostless,  and  then 
assigns  it  the  first  host  suitable  for  its  generic  class. 
The  handler  of  message  rejections  ( Reject Outpu tMess , a 
subroutine  of  RecordMESSX RE J ) recognizes  a transaction  that 
has  been  marked  as  hostless,  and  chooses  the  next  host  in 
the  list.  If  the  list  is  exhausted,  the  pending 
SendGener icMessage  is  aborted. 

When  a generic  message  is  received,  MSG  first  looks  for 
a destination  process  of  the  right  category  that  has  issued 
a ReceiveGener icMessage.  If  none  is  available,  it  will  try 
to  start  a new  process  of  the  generic  category  and  deliver 
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the  message  to  the  new  process.  If  the  quota  for  such 
processes  has  been  reached*  and  the  option  of  holding  the 
message  has  not  been  ruled  out  by  the  sender,  MSG  will  queue 
the  message  in  the  Ir.putMessQ  for  the  generic  category  until 
a process  issues  a matching  Receive  or  until  a new  one  car. 
be  created. 

2.3.  1.4  Message  Flow  Control 

To  help  determine  when  to  request  that  a message  be 
held  by  its  sender  and  when  to  prompt  its  retransmission, 
MSG  maintains  two  counts  for  each  potential  destination 
process  and  for  each  generic  category.  The  first, 
FreeBuf ferSize , gives  the  amount  of  text  buffer  space 
alloted  to  the  process  that  is  not  already  in  use  by 
messages  to  or  from  that  process.  The  second, 

CommittedBuf fer Space , is  the  total  text  length  of  the 
messages  currently  being  retransmitted  by  their  senders. 
The  value  of  FreeBuf  fer  Si  ze  less  CommittedBuf  fer-Space  is 
called  VirtualFree Space.  V irtualFreeSpace  :s  used  to  decide 
when  to  stimulate  retransmission  by  sending  XMIT.*  When  its 
value  rises  above  a threshold,  either  through  the  freeing  of 
some  buffer  space  or  the  timeout  of  an  expected 

retransmission,  MSG  looks  in  the  appropriate  Ir.putMessQ  for 
a held  message  to  call  in.  Of  course,  the  commitment  of 
buffer  space  is  net  absolute.  Unanticipated  messages  may 
arrive  and  be  accepted  before  the  one  retransmitted,  forcing 
its  further  delay.  It  seems  likely  however,  that  the  simple 
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algorithm  chosen  will  perform  well  in  most  cases.  If  not, 
the  model  leaves  ample  latitude  for  changing  it. 

2.3.  1.5  Sequencing  of  Messages  Marked  For  Special  Handling 

As  mentioned  ir  the  introduction,  the  MSG  specification 
defines  two  classes  of  messages,  called  sequenced  and 
stream-marked  messages,  for  which  special  rules  govern 
delivery  order.  All  sequenced  messages  from  a given  source 
to  a given  destination  must  be  delivered  ir  the  order 
submitted,  and  failure  of  one  such  message  inhibits  any 
further  sequenced  message  flow  between  the  processes  until 
the  source  process  executes  a Resynch  primitive. 
Stream-marked  messages  must  be  delivered  after  completion  of 
any  prior  output  messages  to  the  same  destination  and  before 
delivery  of  any  subsequent  messages.  Failure  of  a 
stream-marked  message  inhibits  all  further  message  traffic 
from  the  source  to  the  destination  until  a Resynch  is  issued 
by  the  sender. 

Message  sequencing  is  effected  entirely  by  the  sending 
MSG  (see  Er.QHostSpecif icMess)  , which  checks  before 
transmitting  any  message  whether  there  is  an  existing 
incomplete  message  to  the  same  destination  that  blocks 
transmission  of  the  current  message  under  the  rules.  (This 
is  the  reason  OutputMessQ  is  a queue  and  not  a set.)  The 
transaction  is  placed  in  the  special  state  "Awaiting  prior 
MESS  completion" . 
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Later,  when  a prior  message  transaction  completes 
successfully,  the  subroutine  AcceptOu tputMess  scans  the 
output  queue  for  later  messages  that  are  unblocked  by  the 
completion,  and  it  sends  these  messages.  When  a prior 
message  is  aborted,  a similar  scan  occurs  (in  subroutine 
RejectOutputMess) ; however,  in  this  case  it  may  be  necessary 
to  abort  some  of  the  blocked  message  transactions  because  a 
sequenced  or  stream  marked  message  has  failed.  If  so,  a set 
of  "inhibited  destinations”  ( Ir.hibitedDestS)  is  updated  for 
the  source  process,  to  ensure  that  further  messages  (or 
possibly  just  sequenced  messages)  to  the  same  destination 
are  inhibited  pending  a Resyr.ch. 

2.3- 1.6  Strictly  Local  Transaction s 

When  the  destination  of  a message  is  a process  on  the 
same  host  as  the  source  process , the  network  interface  is  of 
course  not  used.  However,  the  queue  management  routines 
behave  in  most  respects  as  though  the  message  were  being 
transmitted  betweer  distinct  hosts.  A separate  transaction 
record  is  created  for  the  "incoming”  message  (though  not 
necessarily  a separate  copy  of  its  text)  when  it  is  passed 
from  the  output  handlers  to  the  input  handlers.  It  may  even 
happen  that  the  message  will  be  "Held  by  sender",  if  the 
buffers  alloted  to  the  destination  process  are  too  full  to 
permit  accepting  it.  Locally  held  messages  are  given 
priority  over  others,  however,  since  the  response  to  a local 
"XMIT"  request  is  instantaneous. 
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2.3.3  Handling  of  Alarms 

Alarm  handling  in  MSG  is  just  like  message  handling, 
but  without  several  of  the  compl icatiors . Generic 
addressing  and  sequencing  are  not  issues.  Text  buffering  is 
no  problem  since  alarms  have  only  a fixed  length,  very  short 
alarm  code.  The  MSG-to-MSO  protocol  for  alarms  does  not 
permit  requests  analogous  to  MESS-HOLD,  so  the  state 
diagrams  for  input  and  output  alarms  are  trivial.  Handling 
of  local  (intraMSG)  alarm  transmissions  is  identical  to  that 
for  messages.  The  only  special  feature  of  alc.rm 
transactions  is  that  a process  may  choose  to  reject  all 
incoming  alarms  by  setting  its  IAccept  flag  to  FALSE  (using 
the  AcceptAlarms  primitive).  MSG  simply  checks  this  flag 
before  accepting  ar.  alarm,  and  rejects  the  alarm  when  che 
flag  is  off. 

The  model  uses  the  name  " Rece iveAlarm”  instead  of 
" Enable Alarm”  (used  in  the  MSG  specification),  to  emphasize 
the  analogy  with  R»  ceiveMess.  The  routines  in  QUEUE  that 
deal  with  alarms  are  Er.QOutput  Alarm , En.Q  Input  Alarm , 
RecordALA RM\0K,  and  Record ALA RM\ RE J . 

2.3.4  Handling  of  Direct  Connections 

The  establishment  of  direct  connections  between  MSG 
user  processes  differs  in  several  respects  from  the 
transmission  of  messages  or  alarms.  The  roles  of  sender  and 
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receiver  do  not  exist.  Instead,  both  processes  agree  to 
oo^n  the  connection  by  executing  matching  OpenConn 
primitives,  and  they  close  it  (in  the  normal  case)  by 
issuing  similar  CloseCor.r.  primitives.  A connection 
transaction,  unlike  a message  or  alarm,  does  not  end  with 
the  completion  of  the  primitive  that  initiated  it,  since  a 
record  must  be  maintained  for  use  in  closing  the  connection. 
Special  provision  is  also  necessary  for  signalling  a local 
process  that  a connection  has  been  broken  other  than  by  a 
normal  closing  sequence.  MSG's  handling  of  direct 
connections  is  diagrammed  in  figure  4. 


The  events  that  _,ive  rise  to  transitions  are  the 
execution  of  OpenConn  and  CloseConn  primitives  by  the  local 
process  and  the  receipt  of  CONN-OPEN,  CONN-CLOSE,  and 
CONN-REJ  protocol  items  from  a remote  MSG.  MSG  instances 
exchange  CONN-OPEN  items  before  opening  a connection  between 
the  two  processes  requesting  it.  They  exchange  CONN-CLOSE 
items  either  when  requested  to  close  a connection  or  when  a 
connection  cannot  be  opened  because  of  a mismatch  in 
parameters.  CONN-REJ  is  used  to  rejec  either  a CONN-OPEN 
or  a CONN-CLOSE  that  is  invalid. 


In  the 

initial  state  of  figure 

labelled 

"No 

connection"  , 

the  receipt  of  a CONN-OPEN 

item 

(transition 

2) 

creates  a transaction  record  and  leaves  it  in  state 
"Awaiting  OpenConn",  that  is,  awaiting  local  execution  of  an 
OpenConn  primitive  for  a matching  connection.  When  the 
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Awaiting 
CONN- OPEN 


Mismatcn  - 
awaiting 
CONN-CLOSE 


Awaiting 

CONN-CLOSE 


Awaiting 

CloseConn 


Await i ng 
OpenConn 


Open  Conn/send  CONN-OPEN 
CONN-OPEN/  -- 
CONN -C LOS E/send  CONN-REJ 
CONN-REJ/  -- 

CONN -0 PEN /open  connection, 
complete  OpenConn 
CONN-OPEN/s.end  CONN-CLOSE 
CloseConn/ send  CONN-CLOSE, 
abort  OpenConn 
CONN-CLOSE/ abort  OpenConn, 
send  CONN-CLOSE 
CONN-RE J/abor t OpenConn 
Timeout/abor t OpenConn 
send  CONN-CLOSE 
CONN-CLOSE/  -- 
Close Conn /send  CONN-CLOSE 
Error/send  CONN-CLOSE 
OpenConn/ s \nd  CONN-OPEN, 
complete  OpenConn 


Connection 

open 


OpenConn/send  CONN-RE. 

abort  OpenConn 
Timeout/send  CONN-REJ 
CONN-OPEN/  -- 
C0NN-CL0SE/3bort  Clos* 
COMN-REJ/abort  CloseCc 
Timeout/abort  CloseCo' 
Close Co nn/abor t 0 penCc 
CONN -CLOS F./abor t Open! 
CONN-REJ/ abort  Open Co: 
Timeout/ abort  OoenCon: 
CONN-CLOSE/ complete  e\ 
CONN-REJ/ccmpiete  ever 
Timeout/complete  even; 
Close  Conn/send  CONN -Cl 
close  connection, 
complete  CloseConn 
Timeout/c.' os 3 connect 
signal  broken  connec 


Figure  4.  State  Transitions  for  Direct  Connections 
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local  open  is  issued,  the  connection  types,  directions,  and 
byte  sizes  supplied  by  the  two  sides  are  compared.  If  they 
match,  the  transaction  is  placed  in  the  "Connection  open" 
state  (transition  10),  the  network  connection  is  opened  (by 
the  process  delivery  server),  and  the  open  primitive  is 
completed  normally.  If  the  connection  specifications  do  not 
match,  then  a CONN-RE J is  sent  to  the  remote  MSG,  and  the 
OpenConn  is  aborted  (transition  11). 

Other  possibilities  while  "Awaiting  OpenConn"  are  that 
the  remote  MSG  may  wish  to  close  the  connection  before  it  is 
open  by  sending  CONN-CLOSE,  or  that  the  local  transaction 
may  time  out.  In  the  former  case,  MSG  responds  with  an 
answering  CONN-CLOSE;  in  the  latter,  it  sends  CONN-RE J as  a 
reply  to  the  original  CONN-OPEN.  In  either  case,  the 
transaction  is  deleted  from  the  data  base  (transition  11). 

If  the  local  or  n precedes  the  remote  open,  the  state 
of  the  transaction  reaches  "Connection  open"  via  transitions 
1 and  4 and  the  intermediate  state  "Awaiting  CONN-OPEN".  In 
this  case,  however,  if  connection  parameters  do  not  match,  a 
full-fledged  connection  close  sequence  is  used,  since  a full 
open  sequence  will  have  been  completed  by  the  time  the 
mismatch  is  discovered.  The  local  MSG  sends  a CONN-CLOSE 
item  (transition  5)  to  terminate  the  transaction,  and  places 
the  transaction  in  the  state  "Mismatch  - awaiting 
CONN-CLOSE"  to  wait  for  an  answering  CONN-CLOSE. 
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If,  while  MSG  is  "Awaiting  CONN-OPEN”,  a CONN-REJ  is 
received  instead,  or  if  the  transaction  times  out  waiting 
for  a reply,  the  local  OpenCor.n  is  aborted  and  the 

transaction  expunged  (transition  7). 

Once  the  connection  is  open,  an  exchange  of  CONN-CLOSE 
items  will  lead  to  its  orderly  closing.  The  path  from 
"Connection  open”  to  "No  connection"  leads  either  through 
"Awaiting  CloseConn"  or  "Awaiting  CONN-CLOSE"  (transitions  3 
or  9),  depending  on  the  order  of  events.  If  the  transaction 
times  out  while  a local  close  is  awaited,  a special 
"connection  broken"  signal  will  be  sent  to  the  user  process, 
if  such  a signal  has  been  specified  in  opening  the 

connection . 

The  transition  diagram  is  complicated  by  the  fact  that 
it  is  possible  for  a user  process  to  execute  an  Open  Conn 
primitive  and  then  a CloseConn  before  the  OpenCor.n  has 
completed.  There  are  two  states  in  which  an  OpenCor.n  can  be 
pending,  "Awaiting  CONN-OPEN"  and  "Mismatch  - awaiting 
CONN-CLOSE".  In  both  cases,  the  pending  open  is  aborted 
immediately  when  the  CloseConn  is  issued.  From  "Mismatch 
awaiting  CONN-CLOSE",  the  successor  state  in  this  case 
(transition  14)  is  "Awaiting  CONN-CLOSE",  the  usual 
intermediate  state  when  a CloseConn  is  pending.  The 

CONN-CLOSE  item  from  the  local  to  the  remote  MSG  will 

already  have  been  sent  when  the  mismatch  was  discovered. 
From  "Awaiting  CONN-OPEN"  a CloseConn  takes  the  transaction 
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into  the  special  state  labelled  "Awaiting  CONN-OPEN  or 
CONN-CLOSE"  (transition  13).  A CONN-CLOSE  is  sent  by  the 
local  MSG,  but  it  may  or  may  not  reach  the  remote  MSG  in 
time  to  prevent  a CONN-OPEN  in  reply  to  the  original 
CONN-OPEN  sent.  The  special  state  is  included  to  receive 
and  ignore  that  reply,  if  it  comes  (transition  12). 

The  routines  in  QUEUE  that  implement  handling  of  direct 
connections  are  Er.QOutpu tOper. Corn  , EnQOu tputCloseCorn  , 
EnQInput  Open  Conn  , Er.Q  In  put  Close  Conn  , and  RecordCONNXRE J . 


2 . ^ Cancellation  o f Incomplete  Transactions 

The  CANCEL  module  contains  the  routines  that  dispose  of 
transactions  that  cannot  be  successfully  completed.  This 
may  happen  because  1)  the  user  Rescinds  the  transaction,  2) 
the  user  process  terminates  and  a StopMe  is  performed,  3)  a 
protocol  item  is  waiting  to  be  output  and  the  host  to  which 
the  item  is  addressed  dies,  or  4)  the  transaction  is  timed 
and  the  timer  expires.  When  a transaction  is  cancelled  two 
basic  types  of  action  are  necessary  --  the  transaction  must 
be  finally  disposed  of  locally,  and  the  remote  MSG  must  also 
cancel  its  version  of  the  transaction.  The  precise  form  of 
the  action  depends  on  the  transaction’s  state. 

Local  cleanup  of  a transaction  generally  consists  of 
removing  it  from  its  owning  process’s  transaction  lists  (the 
owning  process  is  the  one  for  which  the  transaction  was 


-rrr  . 
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created  ar.d  whose  lists  contain  it)  and,  if  it  is  a pending 
event,  delivering  it  to  that  process.  For  example, 
cancelling  a transaction  in  the  "Awaiting  CONN-OPEN"  state 
involves  removing  it  from  its  owning  process’s  connection 
set  and  completing  the  Open  Conn  pending  event  that  initiated 
it.  Local  message  transactions  are  treated  specially.  They 
are  exceptional  in  that  both  source  and  destination 
transactions  are  available,  and  are  thus  both  cancelled 

5 

locally  at  the  same  time. 

Remote  cancellation  is  generally  accomplished  by 
sending  a protocol  item  to  the  remote  MSG.  For  example, 
sending  a MESS-CANCEL  item  car.ceis  a transaction  in  the 
"Awaiting  XMIT"  state.  It  may  be  that  a prior  protocol  item 
related  to  the  transaction  being  cancelled  is  waiting  to  be 
sent,  in  which  case  the  item  can  simply  be  changed  to 
reflect  cancellation.  For  example,  a transaction  may  be  in 
the  "Awaiting  XMIT"  state  with  a HOLD-OK  item  waiting  to  be 
sent  --  changing  the  item  to  MESS-CANCEL  cancels  the 
transaction.  It  is  also  the  case  that  cancellation  can  be 
effected  by  not  sending  a protocol  item.  Such  an  item, 
initiating  an  MSG-MSG  negotiation  and  waiting  to  be  sent, 
can  be  removed  and  the  transaction  nipped  in  the  bud.  For 
example,  a transaction  may  be  in  the  "Awaiting  CONN-OPEN" 
state  with  a CONN-OPEN  item  waiting  to  be  sent  — removing 
the  CONN-OPEN  item  cancels  the  transaction  before  the  remote 
MSG  has  heard  anything.  A transaction  may  also  be  cancelled 
by  doing  nothing,  relying  on  the  system's  response  to  the 
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receipt  of  spurious  protocol  items.  For  example,  a 
transaction  in  the  "Awaiting  HOLD-OK"  state  can  be  cancelled 
simply  by  removing  all  local  knowledge  of  the  transaction. 
Later,  if  the  remote  MSG  sends  a HOLD-OK  item  for  a 
transaction  that  no  longer  exists,  the  system  will  reply 
with  a MESS-REJ.  ' 

The  four  routine.*  that  call  LocalCar.cel  and 
RemoteCancel  reflect  the  four  causes  for  transaction 
cancellation  --  Rescind  Pend ingEvent , StopTr ansaction , 
HostDeadTransactior.  and  Timeou tTr ansact ion . The  first  two 
are  invoked  from  the  user  call  servers,  the  third  from  the 
network  output  servers,  and  the  fourth  from  the  timeout 
handler  — from  at  least  three  MSG  paths.  This  gives  rise 
to  contention  issues.  In  order  to  dispose  of  a transaction 
both  the  transaction  record  and  the  record  for  its  owning 
process  must  be  seized.  The  user  call  server  has  the 
process  and  needs  the  transaction,  while  the  network  output 
server  and  the  timeout  handler  have  the  transaction  and  need 
the  process.  The  user  call  server  is  given  priority.  The 
network  output  server  and  timeout  handler  do  a non-blocking 
test-seize  of  the  transaction  and  its  owning  process.  If 
the  test  fails  they  go  on  to  other  transactions,  returning 
later  and  trying  again. 

Whether  or  not  a pending  event  is  rescissible  depends 
on  whether  the  event  can,  with  certainty,  be  cancelled 
remotely.  For  example,  an  event  in  the  "Awaiting  XMIT" 
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state  can  be  cancelled  with  certainty  by  sending  a 
MESS-CANCEL  item.  On  the  other  hand,  an  event  in  the 
"Awaiting  MESS-OK"  state,  with  a MESS  protocol  item  already 
sent,  cannot  be  rescinded  because  the  message  may  already 
have  been  accepted  remotely  (with  a MESS-9K  response  on  the 
way).  Sending  a MESS-CANCEL  item  would  not  necessarily 
succeed.  Using  this  certainty  test,  Rescind  Pend ingEvent 
determines,  based  on  the  state  of  the  event  passed  to  it, 
whether  that  event  is  rescissible. 

The  CANCEL  module’s  province  also  includes  transaction 
timing.  Transactions  are  timed  so  that  users  receive 
definitive  dispositions  of  pending  everts  without  having  to 
wait  indefinitely  in  uncertainty,  and  so  that  the  MSG 
resources  used  by  a transaction  may  be  freed  after  an 
inordinate  delay  in  completing  the  transaction.  A 
transaction  is  timed  when  it  is  in  the  queue  of  the  timeout 
handler.  The  queue  is  sorted  by  timeout  deadline,  the 
transaction  timing  out  earliest  being  at  the  front  of  the 
queue.  StartTiming  inserts  an  entry  into  the  timer  queue 
and  StopTimirg  removes  one. 

TimeoutHandler , the  routine  comprising  the  timeout 
handler  path,  processes  transactions  which  have  timed  out. 
The  SIGNAL  mechanism  is  used  to  awaken  TimeoutHandler  when 
timeout  occurs.  TimeoutHandler  obtains  and  WAITs  on  a 
signal  activated  when  the  deadline  of  the  transaction  at  the 
front  of  the  timer  queue  expires,  and  cancels  the 
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transaction  when  the  signal  is  received.  Timeout  Handler 
WAITs  additionally  for  a signal  from  StartTimir.g.  If  the 
transaction  passed  to  StartTimir.g  will  time  out  earlier  than 
the  earliest  existing  timer  queue  entry,  TimeoutHar.d ler  must 
be  notified  to  wait  for  the  new,  earlier  deadline  rather 
than  the  old,  later  one. 

2 . 5 T Network  Interface 

The  routines  that  maintain  communication  with  other 
MSGs  are  found  in  the  REMOTE  module.  They  establish 
inter-MSG  network  connections  and  exchange  protocol  items 
over  them. 

Connections  are  opened  for  two  reasons.  A local  user 
process  may  wish  to  communicate  with  a remote  one  on  a host 
with  which  no  connection  exists,  in  which  case  the  local  MSG 
initiates  an  Initial  Connection  Protocol  sequence  with  the 
MSG  on  the  desired  host.  Alternatively,  a remote  MSG  may 
desire  to  establish  a connection,  starting  an  ICP  sequence 
to  which  the  local  MSG  must  respond. 

When  a connection  is  initiated  locally,  the  user  call 
server  enters  the  remote  host  in  Hosts,  assigns  the  host  to 
a network  server  pair,  possibly  creating  new  servers  for 
this  purpose,  and  notifies  the  output  server,  via  a special 
entry  in  the  server’s  delivery  queue,  that  an  ICP  should  be 
initiated.  (This  occurs  in  the  Sei zeHostHandle  routine). 
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The  output  server  performs  the  ICP  request.  establishing  the 
sockets  to  be  used  for  the  correction  (in  RequestICP).  If 

the  ICP  request  should  fail,  all  protocol  items  waiting  to 

be  sent  to  the  unresponsive  host  are  cancelled  via 
action.  The  other  MSG's  authentication  demand,  in  response 
to  the  ICP  request,  is  handled  asynchronously  by  the 

authentication  handler  path  ( Auther.ticationHan.dler) . 

When  a remote  MSG  initiates  a connection  the  ICP 

handler  path  (ICPHar.dler)  responds  to  its  request.  It 
authenticates  the  requesting  entity  as  an  MSG,  establishes 
the  sockets  to  be  used  for  the  connection , makes  the  Hosts 
entry,  allocates  servers,  and  finally  notifies  the  outp 
server,  by  enqueuing  a special  entry  in  its  delivery  queue, 

that  a connection  should  be  opened. 

In  both  cases  the  output  server  (in  the  routine 
opens  the  MSG-to-hSG  correction,  «<*"■■«•• 

ir.  forma  tier.  ait.  too  remote  “ 

transactions  to  the  r..»  boat  with  the  -org  ircarraUor 
number , and  notifies  tb.  input  server  that  the  ».» 
exists . 

The  basic  action  taken  when  an  error  occurs 
network  connection  is  th.  closing  of  th.  connection  and  the 
deallocation  of  th,  socket.  This  is  don.  b,  th.  sen.en  that 
detects  th.  error.  Additional!,,  if  the  correction  closed 
was  the  onl,  oh.  to  that  remote  host,  the  correction  is 
replaced  by  entering  a Start  ICP  item  at  the  front 
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queue  of  the  appropriate  output  server.^ 

When  properly  functioning  connections  with  another  MSG 

$ 

exist  they  are  used  for  exchanging  protocol  items,  the  units 
of  inter-MSG  cot  .icatior. . The  process  of  sending  and 
receiving  protocol  items  has  two  parts.  Internal  data 
structures  must  be  converted  to  and  from  the  external 
protocol  formats  recognized  by  all  MSGs,  ar.d  those  external 
items  must  be  sent  and  received  over  the  network.  In  the 
abstract  model,  these  conversions''  are  defined  in  terms  of 
pseudo  data  structures,  thus  making  them  non-procedural  and 
separate  from  network  data  transmission.  This  method  of 
specifying  conversion  provides  clarity  and  modularity, 
aiding  under  stand  ir.g  and  maintenance. 

The  conversion  specifications  are  used  as  templates 
over  buffers  containing  network  data,  imposing  order  on  an 
undifferentiated  mass  of  bits.  They  are  defined  in  a form 
similar  to  the  ELI  STRUCT  operator . The  FORMAT  operator 
takes  a list  of  fields,  each.,  field  corresponding  to  or.e  in 
the  external  protocol  item  being  converted.  Fields  in  the 
FORMAT  definition  appear  in  the  same  order  as  in  the 
external  item.  Ir.  general  a field  is  described  by  a field 
name,  the  data  type  of  the  entity  represented  by  the  field, 
and  the  length  ir.  network  bytes  of  the  field  ir.  the  external 
protocol  item.  For  example,  ir.  the  definition  ot 
MessFormat,  the  first  field  is  Length,  which  contains  the 
number  of  network  bytes  in  the  item.  Its  desired  type  is 
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Short Ir.t  ar.d  it  is  two  network  bytes  long. 

Some  fields  do  not  have  this  form.  Boolean  fields  have 
no  network  byte  length  --  they  are  known  to  be  individual 
bits.  Other  fields  consist  of  several  subfields  occurring 
in  a common  yrttern.  Such  fields  have,  instead  of  a mode 
and  length,  a (indicating  the  existence  of  subfields) 
and  the  name  of  the  FORMAT  where  the  subfields  are  defined. 
For  example,  in  MessForinat  Sour ceProcess  and  DestProcess 
have  the  structure  of  an  MSGProcessName , which  is  defined  in 
a separate  FORMAT.  Other  fields  are  converted  by  routines. 
In  some  cases  these  routines  are  named  in  and  used  by 
FORMAT.  Such  routines,  preceded  by  he  operator,  are 
specified  in  the  type  position  of  the  field  using  them.  For 
example,  in  MSGProcessName  Ger.ericName  is  converted  by 
Gener ic Class . In  other  cases  conversion  routines  are 
invoked  independent  of  FORMAT.  Fields  converted  in  such  a 
manner  appear  in  FORMAT  definitions  as  documentation.  They 

are  indicated  by  a " " in  the  type  position.  For  example, 

the  message  text  field  in  MessForinat  is  handled  by  special 
text  moving  routines,  but  the  text’s  presence  is  documented 
by  the  Text  field. 

Many  external  protocol  fields  can  be  converted  and 
assigned  to  and  from  their  internal  representations 
directly,  without  further  processing.  For  example,  in 
ConnOpenFormat  ConnID  is  logically  equivalent  to  ConnID  in 
ConnBlock,  the  target  internal  representation.  On  the  other 
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r s Type  Boolear.s  do  r.ot  correspond  to 
band,  Conn Open Forma t s iyp 

a 'Vi r r Direct ior  , with  further 
Cor.nBlock ' s Cor.r.Type  and  .orr.Directi 

Those  fields  that  car.  be  assigned 

Drocessing  necessary. 

directly  are  indicated  in  a FORhftT  by  T»c,  -t  .... 

*.  ,«  « *“  l'reet 

fihip  to  collective 

field.  Such  fields  arc  susc.pttbl 

assignment,  -here  . -hole  it.,  is  assisted  tc  at,  fro.  its 
ir.terr.al 

mentioned . 

,,eeH  ir.  the  network 

FORMAT-de fined  conversions  ar 

tvs ^ y are  invoked  by  the 
input  and  output  servers.  Th-Y 

4-  The  ! ! operator  specifies 

„,«t  ..<•;«•  and  operator;) . The  , , P 

the  FORMAT  to  be  imposed  on  the  network  buff  , 

operatcr  rcfcrecccs  a ,.r«.r  «•»  « 

i-cr  example,  in  PrctcccUr.put  the  header  FORh.T  is  used 

to  retrieve  (!)  the  Command  field  in  it.  The  <.. 
eperaters  .re  uaed  tc  Perform  the  collective  assignment. 

4-vma  1 oDerator  or  every 

They  obviate  the  need  for  using 

field.  for  example,  in  InputMess  the  <ii  operator  assigns 

.il  g-marked  fields  it  «...*:•■*  “* 

puffer  tc  the  Interest  hessBlook,  and  * <>utput»..s  1.>  doe 

the  reverse.  Beth  operates.  , lsc  set  the  FOKhAT  to  Pe  used 

uha.  after  Cl  or  i ^ be 

by  the  ! operator,  so  that  after 

employed  for  individual  fields-  hen  “ 

InputCpr.nOpen  translatier.  Petueer-  the  external  Type  Beole.r-S 
and  the  internal  Cotnlype  and  Conn.Direction  fields 

performed  using  I • 
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Both  the  network  input  server  and  the  network  output 
server  have  a similar  structure.  Each  is  organized  around  a 
dispatcher,  which  transfers  control  to  routines  specialized 
for  processing  specific  protocol  items.  The  input 
dispatcher,  Protocol  Input , waits  for  an  item  to  come  in  on 
one  of  its  network  channels,  while  the  output  dispatcher, 
Protocol  Output , sends  out  items  put  in  its  delivery  queue. 
The  item-specific  routires  perform  FORMAT-def ir.ed  assignment 
to  and  from  the  network  data  buffer  and  the  proper 
transaction  record  and,  in  the  case  of  input,  call  the 
ap' •'opriate  QUEUE  routine. 
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3.  The  Language  o_~  the  Model 

The  MSG  ab  act  model  is  written  in  ELI  [Manual],  the 
base  language  , the  ECL  system,  which  hosts  the  testbed  for 
our  program  development  experiments.  During  refinement,  ELI 
text  will  be  reduced  to  SPECL,  a systems  programming  version 
of  ELI,  and  then  into  BLISS,  ar.  implementation  language. 
BLISS  was  chosen  because  there  are  BLISS  compilers  for  both 
of  the  machines  for  which  we  plan  to  make  MSG  realizations. 

Because  the  systems  resulting  from  refinement  must  be 
independent  of  the  ECL  runtime  facilities,  we  have  taken 
care  to  ensure  that  dependence  on  certain  ECL  features  will 
be  easy  to  remove.  The  model  uses  explicit  freeing  of 
records  allocated  in  the  data  b3se,  for  example,  because 
garbage  collection  will  usually  not  be  practical  in  a 
concrete  instance,  and  because  determining  by  mechanical 
analysis  when  storage  can  be  reclaimed  remains  a difficult 
research  problem. 

The  modelling  language  also  includes  extensions  to  ELI 
which  aid  readability  and  provide  the  freedom  to  refine 
certain  expressions  in  a variety  of  ways.  Some  of  these 
ex  tensions  are  specially  handled  by  the  tools  used  in 
refinement . 


c 
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3. 1 Data  Type  Generators 

The  model  makes  use  of  operators  for  type  creation  that 
are  r.ot  part  of  ELI,  but  that  have  behaviors  related  to 
similarly  named  base  language  type  generators.  Pointer , for 
example,  constructs  types  whose  instances  behave  like 
pointers,  but  could  be  implemented  either  as  machine 
addresses  or  table  indices.  Value  is  the  operator  used  to 
dereference  an  abstract  pointer.  Sequejnc e denotes  a class 
of  objects  that  are  homogeneous  indexable  collections, 
without  pinning  down  whether  its  members  are  of  fixed  or 
variable  length.  Union  types  represent  objects  whose  types 
are  not  fixed  until  runtime;  type  tags  and  hidden  pointer 
levels  may  be  used,  or  it  may  be  possible  to  avoid  this 
overhead.  En urn e r a t i o n produces  a type  whose  elements  are 
members  of  a set  of  tokens  fixed  when  the  type  is  generated. 
Constants  of  an  enumeration  type  are  delimited  by  double 
quotation  marks.  (The  ELI  builtir.  type  SYMBOL,  whose 
literals  are  normally  indicated  by  double  quotes,  is  not 
used  per  se  in  the  model  since  it  implies  runtime  hash  table 
maintenance . ) 

The  type  operator  HAS  creates  heterogeneous  record 
types  from  tuples  containing  field  names  and  component 
types.  HAS  will  also  be  used  later  in  MSG  development  to 
effect  type  refinement  --  adding  additional  fields  to 
existing  types  to  satisfy  needs  that  arise  at  lower  levels 
of  abstraction. 
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3.2  Set  and  Queue  Ab s t r a c t i o r. s 

The  model  makes  use  of  two  abstract  type  generators 
that  are  neither  explicitly  defined  nor  analogous  to  base 
language  operators.  Set(M)  represents  an  unordered, 
non-repeating  collection  of  objects  of  type  M.  Insert  and 
Remove  are  generic  procedures  that  enter  and  delete  elements 
from  sets.  Queue(M)  denotes  an  ordered,  fixed-capacity 
collection  of  M-values  that  need  not  be  unique  within  the 
collection.  EnQ  and  DeQ  are  generic  procedures  that  enter 
and  delete  queue  elements.  Front  is  a function  that  returns 
the  least  recently  entered  element  of  the  queue  it  is 
applied  to.  IsFullQ  is  a predicate  that  returns  TRUE  when 
applied  to  a queue  that  has  reached  its  capacity. 

The  names  of  sets  in  the  model  are  conventionally 
terminated  with  a capital  S (e.g.,  Connections);  names  of 
queues  end  with  a capital  Q (e.g.,  InputAlarmQ) . 


3. 3 Iteration  Expressions 

To  ensure  that  the  model  routines  that  deal  with 
collection  abstractions  remain  independent  of  the 
representations  chosen,  we  use  abstract  iteration 
expressions.  The  general  form  of  these  loops  is 

FOREACH  E AT  P IN  C DO  SI;  . . . ; Sk  END 

This  expression  will  bind  the  identifier  E to  successive 
elements  of  the  collection  C and  execute  the  statements  SI 
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through  Sk  or.ce  for  each  such  binding.  As  with  ELI 
iterations,  any  statement  Si  may  have  the  fo~m  B =>  R,  where 
B and  R are  expressions  and  B yields  a Boolean  result.  If, 
when  such  a statement  is  executed,  B evaluates  to  TRUE,  then 
the  loop  is  terminated  and  the  value  of  R becomes  the  value 
of  the  loop. 

The  clause  AT  P is  optional.  When  it  appears,  the 
identifier  P will  be  bound  on  successive  iterations  to  a 
state  variable  whose  exact  definition  depends  on  the  data 
type  of  the  collection  C.  This  state  variable  can  be  used 
to  efficiently  delete  and  insert  elements  in  the  collection 
during  an  iteration.  For  instance,  the  generic  procedure 
DeQAt(P),  used  during  an  iteration  over  a queue  C,  would 
remove  the  currently  bound  element  from  the  queue.  It  would 
be  equivalent  to  DeQ(C , E) , but  would  be  more  efficient. 

Normally,  the  order  in  which  the  elements  of  a 
collection  are  bound  by  an  iterator  is  not  defined.  To 
guarantee  scanning  of  queues  in  leas t-to-most  recent  order, 
we  use 

FOREACH  E FromFrontOf  Q DO  ...  END 
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APPENDIX:  Text  of  the  MSG  Model 


» 


MSG  . . . Abstract  Version 

The  abstract  version  occupies  the  following  modules: 


GLOBAL 

DRIVER 

PROCESS 

LOCAL 

QUEUE 

REMOTE 

CANCEL 


Common  definitions  and  tables 
(This  module. ) 

MSG  initiation  and  main  routine 
User  program  linkages  to  MSG  primitives 
Code  for  local  process  servers 
Transaction  queue  management  routines 
Code  for  remote  host  servers 
Pending  event  timeout  management 


t «/  mi. 


» 


. Sets,  Queues,  and  Handles  ... 

. In  abstract  MSG,  the  only  difference  between  a "set"  and 

. a "queue"  is  that  the  latter  is  expected  to  conform  to  some 

. queueing  discipline  as  regards  adding  and  deleting  entries. 

. No  commitment  is  made  about  their  representations. 

. A "handle"  designates  a sec  or  queue  entry.  It  has  the 

. abstract  properties  of  a painter.  More  than  one  set 

. and/or  queue  may  contain  the  data  referenced  by  a handle 

. and  thus  share  the  data  referenced  by  the  handle. 

. A handle  is  not  necessarily  represented  as  a physical 

. storage  address  or  pointer. 


. */  ..... 
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f Type  Definitions  ' */  "w; 

Transaction  ID  <- 

i 

. Encoded  version  of  Trar.sactior.Har.dle , 

. used  to  identify  pending  event  for 
. Rescind  primitive  and  as  MSG  network 
. protocol  Source ID  and  DestID. 

Short Ir.t  <-  'Short  integer,  unsigned'  */ 

StateCode  <- 

EhuneratiorC' Null  State" , "Delivered",  "Awaiting  MESS-OK", 
"Awaiting  XMIT",  "Awaiting  MESS", 

"Awaiting  ReceiveMess" , "Held  by  sender", 
"Awaiting  prior  MESS  completion" , 

"Awaiting  HOLD^dK" , "Awaiting  retransmission", 
"Awaiting  ALARM",  "Awaiting  ALARM -OK", 

"Awaiting  ReeeiveAlarm" , 

"Awaiting  COM-OPEN  or  CONN-CLOSE", 

"Awaiting  CONN-CLOSE", 

"Mismatch  - awaitirg  CONN-CLOSE", 

"Awaiting  CONN-OPEN",  "Awaiting  CloseCor.n", 
"Awaiting  Open Corn " , "Connection  open"); 

Conn  Direction  Cede  <-  EnunerationC'In" , "Out",  "InOit"); 

Conr.TypeCode  <- 

EnimerationC' Binary",  "User TELNET" , "Server TELNET") ; 

ProtocolCode  <- 

EhimerationC"  Null  Protocol  Command" , "MESS" , "MESS-OK" , 

"MESS-REJ",  "MESS-HOLD",  "MESS-CANCEL",  "XMIT", 
"ALARM",  "ALARM-OK",  "ALARM-REJ" , "CONN-OPEN", 
"CONN-CLOSE",  "CONN-REJ",  "Start  ICP", 

"Finish  ICP"); 

Cor.nlDCode  <-  Shortlnt; 

HostGode  <-  Short  Ir.t; 

AlarmCode  <-  Shortlnt; 

Generic Cl ass Code  <-  EhumerationC'NullOode" , . ..); 
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Reasor.Code  <- 

Efcuneratior.(»Ir.canpletp",  "Normal",  "ACKir.g  your  close" , 

^Alann  queue  for  process  is  full", 

M Already  have  correct ior.  of  that  ID" 

||Bau  ircarratior.  number  or.  destination  process” 
^Bytesize  giver  is  ir.valid”,  ’ 

^/rocr'3istert  with  correction  ir.fo1' 

correction  byte  size  mismatch”, 

Correction  rot  to  process  named”, 

” Correction  r.ot  yet  open”, 

"Correction  type  mismatch" , ’’Delivered” 

^testiratior.  r.ane/har.dlir.R  - ger.eric/spicifis  misnatch" 
Destination  process  correction  li-nit  reached" 
Destination  process  ur. known" , "Event  rescinded" 

"Event  tined  out",  ’ 

"Failure  of  prior  sequenced  message", 

"Failure  of  prior  stream  marked  messaze" 

Generic  class  giver  is  invalid”, 

:^nr.i  5iver.  is  invalid",  "Host  died", 
insufficient  resources  to  complete  comnar.d", 

Invalid  correction  byte  size”, 

’’Invalid  correction  type”, 

Invalid  host  address  ir.  process  name”, 
ilessage  rescinded  or  timed  out”, 

C^ier.  superseded  by  close”, 

’’Qjtput  messages  quenched”, * 

..^°CeSS  r‘0t  3ccePtiri  alarms  row”, 

^Process  terminated”,  ’’Redundant  close”, 

Referenced  connection  transaction  does  rot  exist” 
Refused  by  all  suitable  bests”,  ’ 

’’Send  message  stream  out  of  synch”, 

||SendGenericMessage” , ’’Ser.dSpecificMessage” , 

Sequenced  send  message  stream  out  of  synch” 
ffSignal  giver,  is  ir.valid”,  ’’Superseded  by  close”, 

„P?at  generic  class  rot  supported  here”, 
iLmed  out  waiting  for  your  CONNECTION -OPEN” 

«n^hfa°^i0o  res=ir-dsj"-  "Transaction  timed  out", 

Utable  to  Rescind”,  "Unknown  connection”); 
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HardlirgCode  <- 

EhuHoratior.C’fbrmal"  , "Sequence"  , "StreamMark"  , "QWait"); 
Strir.2  <-  Sequence( Character) ; 


Strir.gPtr  <-  Poir  ter  (Strir.g) ; 


ProcessName  HAS 

< HastC Hest Cade) , Incarration(Shortlnt) , Ir.star.ceC Short Ir.t) . 
Generic Na ne(  Ur  ior.  (Strir.gPtr , Ger.ericCl  assGade) ) >; 

Process Handle  <-  Pointer (ProcessBlock) ; 


Process  Block  HAS 

< Name (Process Name),  UserCbanr.eK Caar.r.el Handle) , 
OutputMessQOujuoCMessHar.dle)) , 

CUtputAl arm3(Sot(  Alarnllar.  Ue) ) , Corrections (Set(  Ccr.r.  Hnr.dle) ) , 

Ir.putMjssgUueueOtesslIardle)) 

Ir.putAlarmQ(Gueue(  AlarmHar.dle) ) , 

Inh ibitedDestS (Set ( STRUCT (Dest Process: Process Name, 

„ , . Inhibit  All : BOOL) ) ) , 

Del 1 ver  ySo  r v er ( Server Hand 1 e ) L\c c 2 p t ( BOOL ) 

FreeBuffer  Size  (Short  Ir.t) , Committ3dBufferSpace(ShortIr  t) , 
ReceiveMessQQueueObssihrdle)) , 

Race ive A1  a r mQ  ( Cue ue ( A1  a rrn Hand  1 e ) ) , 

CloseCor.nS(Set(GarnHar.dle) ) Termir.ationCTermHandle)  >; 

Generic  Handle  <-  Pointer  (Ger.ericBlock) ; 


Generic Block  BAS 

< Class(Strir.gPtr) , Code(Ger.ericClassCode) , 

Hosts ( Set (rbstGode) ) , Run File( Filename) , 

lerVnr?lSet(ServsrH;3r'dle))  1 lr.putMess3(3ueue(:-tessHardle)) , 
FreeBuf  ferSiza  (Snort  Ir.t) . ComuttedBufferSpaceCSnortlr.t) 
feceiveMess3(MessHar.dle) , Ursupported(BOOL)  >; 

ServerHardle  < - 

Poir. ter (Ur.icr.( In putServer Block,  Cel iveryServer Block)); 

Del iverySer/er Block  HAS 

< Delivery3(Qucue(Trar.3actiorUar.dle)) 

Server  (Procedure) , Ciar.r.elS(Set(GiarrelHardle)) , 
Rur.r.ir.g(300L),  WakeUpSigral(Sigr.alType)  >; 


InputScrverBlock  HAS 

< Server  (Procedure) , Char.neIS(Set(Char.nelHar.dle)) 
WaxeUpSigr.aKSigr.alType)  >; 


> 


ffostHar.dle  <-  Poir.ter(HostBlock) ; 


Ho st Block  HAS 

< Host(HostCpde) , Ir.carratior.(Shortlr.t) . 
Cor.r.ectior.S(Set(Ch3r.rel Handle) ) , 

DeliveryServer(ServerHar.dle),  InputServer(ServerHar.dle)  >; 
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Cham  el  Handle  <-  Poir.ter(CnannalBlock) ; 

Channel Block  HAS  < User (User Handle)  >; 

ContactHar.dle  <-  Pointer  (Cor.tactBlock) ; 

Cor.tactBlcck  HAS 

< RenoteHost(HostHsndle)  ReavoteSocketC  Integer) , 
LocalSocketC Integer) , ProtocolO>Tvnar.d(ProtocolCk>de)  >; 

MessHardle  < Poir ter(MassBlock) ; 

Mess Block  HAS 

< Op(OpCode) . State(StateCode)  Siir.aKSi^ralType)  , 
Dispositior  (ReasonCode) , Deadlir.e(Irte’er) , 

Source  Process  ( ProcessUane)  DestPrccessC  Proc  essHne) 
SjurcelDOVar.sactior.IB) , DsstlDCTrar.sacticr.ID) , 
Text(3trii  ’Per)  TextLsr  -'th(Stortlr.t)  IsCar.ericCBOOL) , 
IsSequer.ced(BOX),  IstoricedOCCL),  tbfbld(BOOL) , 

Ho  Id  Go  y(  BOOL),  Q.,'ait(BOOL) , IslbstlessCBOOL)  >; 
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Gor.nHar.dle  <-  Pointer  (Cor.r. Block) ; 

Cor.r. Block  HAS 

< Op(OpGode),  State(StateCode) , Sigr.al(Sigr.alType) , 
Disposition(Re3SonCode) , D?adlir.e( Integer) , 

Source Process(ProcessName) , Di3tProcess(ProcessName) , 
SourcelD(Transactior.ID) , DestlD(Trar.sactior.ID) , 

Cor.r.  ID  (Conn  IDCode) , Cor.rTypo(  Cor.r  TypeCode) , 

Conn  Direc  tier.  ( Corn  Direct  ion  Code) , Corr.Bytesize  (Short  In  t) , 
Er.dSigr.al  (Sigr.alType) , Correctior(Ch3rrelHardle) , 

Local  Socket (Integer) , RemoteSocket( Integer) , 
ProtocolCo.ninand(ProtocolCode)  >; 

AlarmHar.dle  <-  Pointer ( AlarmBlock) ; 

Alar.n Block  HAS 

< Op(QpCode) , State(StateCoJe) , Sigr.al(SignalType) , 
Dispositior.(Re3sor.Code) , Dcadline( Integer) , 

Saurce Process (Process Name) , De st Process ( Process Name) , 
SourcelD(Trar.sactionlD) , DestlD(Transactior.ID) , 

Alarm  (Alarm  Code)  >; 

TermHar.dle  <-  Poirter(TennBlock) ; 

Term  Block  HAS 

< Op(OpCode) , Sigr.al(Sigr.alType) , Dispositior(ReasonCode) , 
User  Channel  ( Char.r.e  1 Hand  1 e ) > ; 

UserHandle  <-  Unior.(ProcessHandle,  HostHar.dle); 

Transaction  Handle  <- 

Ur.ion(MessHardle,  Aiar.nHar.dle , Conr.Handle,  TennHandle, 
Cont^ctHar.dle) ; 

DestHar.dle  <-  Ur.ion(ProcessHandle,  Ger.ericHandle) ; 


Abstract  Model  of  MSG 
Module  GLOBAL 

’ DATA  ’ */ 

ProcessTable  <-  C0NST(Sequer.ce(Proees3Har.dle) ) ; 

Hosts  <-  CONST  (Set  (Host!  land  le) ) ; 

Ger.ericTable  <-  C0NST(S2quer.ce(GenericHardle) ) ; 

Server  Table  <-  C0N3T(Sequer.ce(ServerHar.dle) ) ; 

Ir.itialServerS  <- 

C0N3T(Set( Procedure)  OF  Auther.ticatior.Handler , ICPdar.dler); 
TimerQ  <-  CONST (Queue (Transaction Handle) ) ; 

Transactior.Table  <-  CONST(Sequence(Transactior.Handle) ) ; 
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PRIMITIVE  PRXEDURES  * V 


Abstract  Channels  ... 

The  following  define  abstract 
channels,  used  for  concur,  ic  a tier,  of  data  between 
paths.  Tney  are  modelled  after  the  channels  used 
in  the  CCN  system. 


. CHOPEN  is  used  to  open  a channels.  Each  path 

. supplies  the  sane  Channel  ID.  The  channel  is  closed 

. if  a CHCLOSE  is  issued  from  either  side,  but 

. will  be  closed  only  after  data  in  the  channel  h3s 

. been  received. 

. CXitput  on  the  charnel  is  assumed  to  be  blocking 

. SEND  (or  =!>),  while  input  blocks  only  if  the 

. third  argument  to  RECEIVE  (or  <!=)  is  TRUE. 

. Nonblocking  input  is  used  in  LOCAL  to  supply 

. locations  for  the  results  returned  at  completion 

. of  a pending  event. 

. Cor.nByteSize  defaults  according  to  the  Type  of 

. the  channel. 

. =!>  and  <!  = are  synonyms  for  SEND  and  RECEIVE. 

. In  certain  implementations  (such  as  TENEX),  they 

. will  be  refined  away  and  be  replaced  by  assignment. 




CHOPEN  <- 
EXPR( Id: Channel ID 

Type :ConnType Code 
Conn  Bytes  i ze : Short  Ir.t ; 
Char.relHardle)  ...; 

SEND  <- 
EXPR(Data:ANY 

Channel : Charnel Handle ; 
ANY)  ...; 

=!>  <-  SEND; 

RECEIVE  <- 
EXPR( Data: ANY 

Channel  .-Channel Handle , 
Blocks : BOOL 
ANY)  ...; 


/*  ’Channel  spec’, 

/*  ’Operating  mode', 

/*  ’Data  to  be  transmitted’, 


/*  ’Where  to  put  received  data’, 
/*  'Blocks  if  TRUE'; 


jria-irrjrrn 


\ 


gy.irtrtli8t1iitrwiipwfcir.rt 


igSSiSi  lariir.-. 
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<!=  <-  RECEIVE; 

<!!==  <- 
t 

. Infix  operator  for  blocking  RECEIVE 

♦ V 

EXPR(Data:ANY,  Channel : Channel  Handle ; ANY) 
RECEIVE (Data,  Channel,  TRUE); 

Make  Id  <- 

i 

. Used  to  construct  a Channel ID 
« for  a network  CHOPEN.  ' #/ 

EXPR( Host: Integer 
RSocket : Integer 
LSocket: Integer 
Channel ID) 


/*  'Remote  hast  (0  for  any)', 

/*  'Remote  socket  (0  for  lister.)', 
/*  'Local  Socket'; 
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» 


DRIVER  - MSG  Initialization  and  main 
routine 


v 


InitiateMSG  <- 
£XPR( Restart: BOOL) 

BEGIN 

Ir.itializeGer.ericS( ) /*  ’Read  the  data  from  disk'; 

(Restart  ->  Kill  User Processes( ) ) /*  1 


. Issue  termination  signals. 

. Also,  d*  op  ar.y  remote  host 
. connections  remaining.’; 

Se  t Ne  wlr.  car  nation  Number  ( ) ; 

Ir.itializeServero( ) /*  ’ 

. Set  up  set  of  servers  to 
. start  up  and  run ' ; 

PollAndSleep( ) /*  ’Tf  servers  are  interrupt-driven, 

enable  them.  Else,  loop  over  Servers 
and  sleep  until  a signal  for 
one  or  more  is  received. 

END; 

Initializes  verS  <- 
EXPRO 

EOREACK  S IN  Ir.itialServerS 
DO 

DECL  SH:  Server  Fiend  le  LIKE  Allocate(ServerBlock) ; 

Sli.  Server  <-  S; 

Release ^SH); 

END; 
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PROCESS  ...  User  Program  MSG  Calls 


1 v 


PRXESS  contains  code  and  data  that 
are  included  in  the  user  program 
to  call  MSG  primitives.  Tne  arguments, 
result  type,  and  the  actual  abstract 
call  for  each  MSG  primitive  are  giver, 
first  below.  Each  primitive  call  is 
represented  as  a call  of  the  abstract 
routine  PCall.  Each  call  is  of 
the  form: 

PCall (Pr imitive Name, Send List , 

ReceiveList , Is  Pending Event) ; 

Each  PCall  call  will  be  refined  according 
to  the  exact  mechanism  chosen  to  communi- 
cate between,  the  user  process  ar.d  local 
MSG  ir.  a given  operating  system  and 
language  implementation. 

The  Sen.dList  and  ReceiveList  include 
all  arguments  of  the  primitive  call, 
classified  as  to  whether  each  argument 
represents  data  sent  to  MSG  by  the  process 
or  data  received  from  MSG  as  a result 
of  executing  the  MSG  primitive. 

. Is Pending Event  is  TRUE  for  those  MSG 

primitives  which  create  pending  events. 

The  communication  algorithm  is  discussed  ir. 

. the  conmentary  preceding  PCall  in  this  file. 

' v 
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Ser.dGer.ericMessage  <- 
EXPR  (Text  .‘String  Per , 

DestProcess : ProcessName, 

Signal  :Sigr.alType , 

Pend  ir.g  Evert  ID:  Transaction  ID, 

Disposition : Reason Code, 

Timer : Integer , 

QWa  i t : Hand  1 i r.g  Code ; 

He a son  Code) 

PCallC'SendGenerioMessage” , 

< Text,  DestProcess,  Signal,  Timer,  Qtfait  >, 

< DestProcess,  Disposition  >,  TRUE); 

ReceiveGenericMessage  <- 
EXPR  (Text  :Strir.gPtr , 

Source  Process : ProcessName , 

Signal  :Sigr.alType, 

Pend ir.g Even  t ID  .‘Transaction ID, 

Disposition : Reason  Code , 

Timer : Integer ; 

Reason  Code) 

PCall(f,ReceiveGenericMessageM , < Signal,  Timer  >, 

< Text,  Source  Process,  Dispositior  >,  TRUE); 

SendSpecificMessage  <- 
EXPR (Text: String Ptr , 

DestProcess : ProcessName , 

Signal : Signal Type, 

Per  ding  Event  ID  :Trar.saction  ID, 

Disposition : Reason Code , 

Timer  .-Integer, 

Har.dl  i r.g : 1 iar  d 1 ir.g  Cod  e ; 

Reason Code) 

PCa  1 1 ( M Send  Spec  i f i.  c Mess  ag e " , 

< Text,  DestProcess,  Signal,  Timer,  Handling  >, 

< Disposition  >,  TRUE); 

ReceiveSpecif lcMessage  <- 
EXPR (Tex t : String Ptr , 

Source  Process : ProcessName, 

Signal : Sigr.alType , 

Pend  ir.g  Even  1 1 D : Tr  an s ac  t i or.  ID , 

Disposition : Reason Code 
Timer  .‘Integer , 

Hand  I i ng : Hand  1 i r.g  Cod  e ; 

Reasor.Code) 

PCalK"  ReceiveSpecif  icMessage" , < Signal,  Timer  >, 

< Text,  Source  Process,  Disposition,  Handling  >,  TRUE); 
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Ser.d Alarm  <- 

EXPR ( Alarm : Alarm Code , 

Dost Process : ProcessName , 

Signal  :Sigr.  a 1 Type, 

Per.d  i r.g  Ev  er.  1 1 D : Tr  ar.  s ac  t i or.  ID , 

Disposition : Reason Code ; 

Reasor.Cods) 

PCall( "Send Alarm” , < Alarm,  Dest Process,  Signal,  Timer  >, 

< Disposition  >,  TRUE); 

ReceiveAlarm  <* 

EXPR (Alarm : Alarm Code, 

Source Process : Process Name , 

Signal  :Sigr.alType , 

Pend  i r.g  Ev  or.  1 1 D : Tr  ar.sac  t ion  I D , 

Disposition : Reasor.Code, 

Timer : Integer ; 

Reasor.Code) 

PCalK” ReceiveAlarm” , < Signal,  Timer  >, 

< Alarm,  Source Process , Disposition  >,  TRUE); 

Open Connect ion  <- 
E XPR ( Conn  ID:  Conn IDCode , 

ConnType : Cor.r.TypeGode , 

Conr.Directior.  :Cor.nDirectior.Code , 

Cor.nBytesize:  Ir.teger , 

DestProcess: ProcessName, 

Er.dSigr.al  :SigralType, 

Signal  :Sigr.alType , 

Pend  i r.g  Ev  er.  1 1 D : Tr  an  s ac  t i on  I D , 

Disposition : Reasor.Code , 

Timer : Integer ; 

Reasor.Code) 

PCall(”Oper.  Connection” , 

< Cor.r.ID,  Cor.r.Type,  Cor.r.Direction,  Cor.nBytesize, 
DestProcess,  Er.d Signal,  Signal,  Timer  >, 

< Disposition  >,  TRUE); 

CloseCor.r.ectior.  <- 
EXPR  (Cor.r.ID:  Tag, 

DestProcess : ProcessName , 

Signal  .-Signal Type , 

Pend  ir.gEver.tID:Tag, 

Disposition : Reasor.Code , 

Timer : Ir.teger ; 

Reasor.Code) 

PCall(”  CloseCor.r.ectior.” , 

< Cor.r.ID,  DestProcess,  Signal,  Timer  >, 

< Disposition  >,  TRUE); 


» 
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Terminatior.S13r.al  <- 
EXPR (Signal  :SignnlType, 

Timer : Integer , 

Disposition : Reason Code ; 

Reasor.Code) 

PCallO'Termir.ationSigral" , < Signal,  Timer  >, 
< Disposition  >.,  TRUE); 


t 

. The  following  primitives  do  not 

. create  per.dirg  events. 

• v 

Stop  Me  <-  EXPR  ( ; Reasor.Code)  PCall ("StopMe"); 

Rescind  <- 

E XPR  ( Pen  J i r.g  Even  1 1 D : Tr  an  sac  t ion  ID ; R2  a son  Cod  e ) 

PCall ("Rescind",  < Pendir.gEver.tlD  >,  < Result  >); 

AcceptAlar.ns  <- 

E XPR (IAccept: BOOL;  Reasor.Code) 

PCallC'AcceptAlarms" , < IAccept  >); 

Resyr.ch  <- 

EXPR (Dest Process: ProcessName ; Reasor.Code) 

PCall  ("Resyr.ch" , < Dest  Process  >); 

Who  Am  I <- 

EXPR  (Name : ProcessName ; Reasor.Code) 

PCall ("Who Am I" , NIL,  < Name  >); 
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PCall  <- 
» 


i 

i 

i 

i 


The  infix  operators  "=!>"  and 
transmission  of  data  from  the 
to  MSG  (SEND  — of.  CHOPEM  ir. 
ar.d  the  reverse.  The  general 


"<!  = " denote 
user  process 
module  GLOBAL) 
protocol  is: 


The  operation  r.ane  of  the  primitive  ar.d  the 
Send Li st  are  sent  to  MSG.  MSG  validates  the 
arguments.  It  returns  a disposition  which 
may  be: 


"Normal"  Execution  is  complete,  and 

the  ReceiveList  return  data  (if  ary) 
should  be  received.  PCall  blocks 
until  reception  is  complete. 

"Incomplete"  A per.dirg  event  has  beer,  created. 

'Hie  r eive  is  issued  to  request 
the  receive  list  data  after 
completion  of  the  pending  event. 

If  the  Signal  is  blockirg,  the 
user  process  blocks;  otherwise, 
PCall  exits  immediately. 

Other  An  error  has  been  noted  by  MSG.  The 
disposition  data  has  been  received. 

No  pending  event  has  been  created. 
PC3II  exits  immediately. 

When  a pending  event  has  successfully 
been  created,  MSG  returns  a Perdir.gEventlD 
to  the  user.  It  is  used  by  the  Rescind 
primitive.  It  is  also  used  in  PCall  to 
open  (usirg  CHOPEN)  an  individual  abstract 
channel  over  which  the  receive  list  data 
is  to  be  returned  by  MSG  at  pending 
event  completion.  MSG  closes  this  channel 
afterwards.  A separate  channel  for  each 
transaction  is  used  to  avoid  cluttering  the 
abstract  model  with  the  details  of  multi- 
plexing use  of  a single  channel. 

*/ 

EXPR  (Op  :0pCode, 

Send List: List, 

ReceiveList : List , 

Creates Pending Event : Bool ; 

Reasor.Code) 

BEGIN 

A # 

9 


Abstract  Model  of  MSG 
Module  PROCESS 


DECL  Result  iReasor.  Code  LIKE  "Normal"; 

t 

. Send  Op  ar.d  Ser.dList  ar^uner.ts 
. to  MSG  ar.d  wait  for  validation 
. result. 

' */ 

Op  =!>  MSGChar.r.el ; 

Ser.dList  =!>  MSGChanr.el; 

Result  <!  !==  MSGCnar.r.el ; 

/#  * 

If  "Incomplete"  (wrier.  CreatesPE  is  TRUE), 
or  "Normal",  Is Abnormal 0 fails’; 
IsAbr.ormaK  Result)  =>  Result; 

Creates Pend in^Event  => 

BEGIN 

t 

. Receive  Per.dir ^Ever.tlD  for  Rescind. 

. Then  open  channel  and  ask  for  ReceiveList 
. return  dat3.  ’ V -; 

Pendir.3Ever.tID  <!  !==  MSGChanr.el; 

DECL  CH:Char.nelHandle  LIKE 
C HO  PEN  ( Pend  i r.5  Ev  er.  1 1 D , In,  Binary); 
ReceiveList  <!=  CH; 

"Normal"; 

END; 

1 

. Rsceive  ar.y  ReceiveList  data. 

' */ 

ReceiveList  <!!==  MSGChar.r.el; 

Result; 

END; 


DATA 


MSGChanr.el  <- 

t 

. Channel  used  to  communicate  with  MSG. 
. Opened  in  Start User  Process. 

• */  CONST (Char.neULir.dle); 
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t 


LOCAL  ...  Local  process  primitive  har.dlers 

' •/ 


» 


. LOCAL  handles  (via  UserCallServer)  user 
. process  primitive  requests  (see  PCall 
. in  PROCESS)  ar.d  delivery  of  results 
. of  primitive  requests  (via  User  Del ivery- 
. Server.) 

. Handlers  for  primitives  that  create 
. pending  events  consist  of  a Start  routine 
. (found  by  looking  up  the  CpCode  in 
. OpTable)  and  an  End  routine  (ir.  Er.dQpTable. ) 
. The  Start  routine  receives  the  Ser.dList  from 
. the  user  process,  validates  arguments, 

. creates  the  per.dirg  event,  ar.d  calls 
. QUEUE  to  have  the  event  enqueued  for 
. further  processing.  Tae  End  routine 
. handles  completion  of  the  pending  event 
. by  sending  the  ReceiveList  data  to 
. the  user  process. 

. Handlers  for  primitives  that  do  not 
. create  pending  events  (e.g.,  DoStopMe) 

. send  any  results  to  the  user  process; 

. in  these  cases,  the  PC311  code  blocks  the 
. user  until  the  results  are  received. 
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1 TABLES  • */ 

Opcode  <- 

EnumeratiortSerdGer.erieMessage,  ReceiveGer.ericMessage, 
Send Specific Message,  ReceiveSpecificMessage , 
Send Alarm,  ReceiveAlarm,  OperCor.r.ectior., 
Close  Correction , Termination Signal , StopMe, 
Rescind,  Accept  Ala  rns,  Resyr.ch,  WhoAmI); 


OpTable  <- 

* Table  of  procedures  to  handle  user  primitive  requests. 
. Start XXX  starts  and  enqueues  a pending  event. 

. DoXXX  completes  the  corresponding  primitive  before 
. returning. 

• */ 

CONST (Sequence (Procedure)  OF 


StartSer.dMessage 

/* 

’Send  Generic  Message', 

Start ReceiveMessage 

/* 

’Receive  Generic  Message’, 

StartSer.dMessage 

/* 

’Send  Specific  Message', 

Start ReceiveMessage 

/* 

’Receive  Specific  Message’, 

Star  end Alarm 

/* 

'Send  Alarm', 

Start  Receive. Alarm 

/* 

’Receive  (enable)  Alarm', 

Star  tCper.Gor.r.ec  tior. 

/* 

'Start  Open  Connection’, 

Start Close  Connection 

/* 

'Close  Connection’, 

StartTermir.atiorSigr.al 

/* 

'Termination  Signal', 

Do  StopMe 

/* 

'Stop  Me' , 

Do  Rescind 

/* 

'Rescind' , 

DoAcceptAlarms 

/* 

'Accept  Alarms', 

Do  Resyr.ch 

/* 

'Resyr.ch' , 

Do Who Ami 

/» 

'Who  Ami ' ) ; 

EndC£>Table  <- 

CONST ( Sequence ( Procedure)  OF 

Er.dSer.dGenericMessage,  Er.dReceiveGenericMessage, 

End Send Spec if ic Message , End  Receive Spec i f ic Message , 

End Send Alarm,  End ReceiveAlarm,  End Open Connection, 

EndCloseConr.ee t ion , ErdTerminatiorSigr.al , 

ErdBrokerCor.r.ectior  /»  ’Not  a primitive... 

. used  to  implement 
. EndSigr.al  for  Oper.Connection' ) ; 

TimerDefaults  <- 

CONST (Sequence (Short Ir.t)  SIZE  LENGTH ( End Cp Table)) ; 
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i 


Primitive  Handlers 


- - ' •/ 

Start Send Message 

EXPR(Op:OpCode,  UserChar.r.el  : Cham  el  Handle,  SP:  ProcessHar.dle) 

BEG  IM 

DECL  M:MessBlcck; 

M.  Source  Process  <-  SP.Name; 

DECL  Handling  iHar.dlir.gCode; 

< M.Text , M.Dest Process,  M. Signal,  M. Deadline,  Handling  > <!  = 
UserChar.r.el ; 

Cor.vertTimer (Cp , M.  Deadline) ; 

DECL  MH:MessHar.dle ; 

M.  Disposition  <-  Reasor.Code  << 

BEGIN 

Op  = "Ser.dSpecif  icMessage"  -> 

IsValidBostC M.Dest Process. Host)  +> 

RETURNO'Inval id  host  address  in  process  name”); 
CASE[Har.dlirg,  Op] 

["Normal"]  =>  TRUE; 

["Sequence” , "Ser.dSpecif  icMessage" ] =>  M. IsSequer.ced ; 
["StreamMark" , "Send Spec if icMessage"]  =>  M.IsMarked; 

["Q.Vait" , "Send  Generic  Me  s sage"  ] =>  M.  IsGer.eric; 

TRUE  =>  RETURN  ("Handling  giver,  is  invalid"); 

END  <-  TRUE; 

OR  (NOT  M.  IsGer.eric, 

Er.codeGer.ericClassCM.DestProcess.Ger.ericClass) , 
CheckBlankGer.ericFields(M. Dest Process) ) //> 

"Generic  class  given  is  invalid"; 

Is ValidSigr.alCM. Signal)  //>  "Signal  giver,  is  invalid"; 

FOREACH  C IN  SP.  Ir.hibitedDestS 
REPEAT 

C.  DestProcess  = VAL(M.DestProcess)  => 

BEGIN 

C.InhibitAll  => 

RETURN  ("Send  message  stream  out  of  syr.ch"); 

M. Sequenced  -> 

RETURN  ("Sequenced  send  message  stream  out  of  syr.ch"); 

END; 

END; 

CheckUserQuench( ) +>  "Output  messages  quenched"; 

MH  <-  Allocate (Mess Handle , M); 

"Incomplete" ; 

END; 

Disposition  =!>  UserChanr.el ; 

Is  Abnormal ( Disposition)  =>  NOTHING; 

MH. UserChanr.el  <- 

C HO  PEN  (MH.  Source  ID  <-  AssignTrar.sactionID(MH)  = 1> 

UserChanr.el,  "Out",  "Binary"); 

EnQOutputMess(MH,  SP); 

END; 
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End Send Mess age  <- 

EXPR (SP: Process Hard  1 e , MH : Me ss Hard  1 e ) 

BEGIN 

DECL  UserChar.nei : User  Data  LIKE  SP.  UserChar.nei; 
MH.IsGer.eric  -> 

BEGIN 

DecodeGerericClass(MH. Dest Process. GenericCl ass) ; 
MH.Dest Process  =|>  UserChar.nei; 

END; 

MH. Disposition  =!>  UserChar.rcl ; 

SIGN AL(MH. Signal) ; 

CHCLOSE  (User  Char.r.el ) ; 

Free(MH) ; 

END; 

Start ReceiveMessage  <- 

EXPR  (Op:  OpCode,  User  Channel : Char.r.el  Handle,  SP:  Process  Handle) 
BEGIN 

DECL  M: Mess Block; 

DECL  MH: Mess Handle ; 

DECL  Disposition : Reason  Code; 

M.DestProcess  <-  SP.None; 

< Signal,  Deadline  XMH)  <1=  User  Channel; 
Cor.vertTimer(Op,  M. Deadline) ; 

Disposition  <-  Reasor.Code  <<  ^ 

BEGIN 

IsValid(MH. Signal)  9>  "Signal  given  is  invalid"; 

MH  <-  Allocate(MessHar.dle,  M); 

" Incomplete"; 

END; 

Disposition  =!>  UserChar.nei; 

IsAbnonnal (Disposition)  =>  NOTHING; 

MH. User Channel  <- 

CHOPEN  (MH.  Dest  ID  <-  Assigr.Transactior.ID(MH)  =!> 

User Channel , "Out",  "Binary"); 
EnQReceiveMess(MH,  SP); 

END; 

End  Re  ceiveMessage  <- 

EXPR(SP:  ProcessHandle,  MH:MessHar.dle) 

BEGIN 

DECL  UserChar.nei:  User  Data  LIKE  SP.  User  Channel; 
DecodeGer.ericClasX  MH.  Source  Process  .Ger.ericClass) ; 

< Text,  Source  Process , Disposition  XMH)  =!>  UserChar.nei 
NOT  MH.IsGer.eric  ->  (EncodeHar.dlir.g(MH)  =!>  UserChar.nei) 
SIGNAL(MH.  Signal); 

Free(MH); 

END; 
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StartSerdAlann  <- 

EXPR((£:  OpCode,  UserChar.r.el : Charnel Har.dle , SP:  Proces.3H2r.dle) 
BEGIN 

DECL  A:AlarmBlock ; 

DECL  AH: Alarm  Bardie ; 

DECL  Disposition : Re ascr. Code; 

A.  Source  Process  <-  SP.Na:ne; 

< Alarm,  Dest Process,  Signal,  Deadline  >(A)  <|= 

User Channel ; 

Cor.  vert  Timer  (Op,  A.  Da  ad  line) ; 

Disposition  <-  Reasor.Code  << 

BEGIN 

IsValidSigr.al(A.Aigr.al)  //>  "Signal  given  is  invalid"; 
AH  <-  Allocate( Alarm  Handle,  A); 

"Incomplete" ; 

END; 

Disposition  = !>  UserChar.r.el; 

Is Abnormal ( Disposition)  =>  NOTHING; 

AH.  UserChar.r.el  <- 

CH0PEN(  AH.  Source  ID  <-  AssignTransactior.ID(AH)  =!> 
UserChanr.el , "Out",  "Binary"); 
EnQOut?utAlarm(AH,  3P); 

END; 

End  Send  Alarm  <- 

EXPfUSP:  ProcessHar.dle,  AH:  Alarm  Har.dle) 

BEGIN 

DECL  UserChar.r.el : User  Data  LIKE  SP.  UserChar.r.el ; 

< Disposition  > ( AH ) =!>  UserChar.r.el; 

SIGNAL(AH.Sigral) ; 

Free(AH) ; 

END; 

Start Receive Alarm  <- 

EXPR(0p  :OpCode , UserChar.r.el  :Chanr.elHar.dle,  SP:  ProcessHar.dle) 
BEGIN 

DECL  A:AlarmBlock; 

DECL  AH:AlarinHandle ; 

DECL  Disposition  .-Reasor.Code; 

A.DestProcess  <-  SP.Name; 

< Signal,  Deadline  >(A)  <!=  UserChar.r.el; 

Cor.vertTimer(Op,  A. Deadline) ; 

Disposition  <-  Reasor.Code  << 

BEGIN 

IsValidSigr.alC A. Signal)  //>  "Signal  given  is  invalid"; 
AH  <-  AllocateCAlarmHar.dle,  A); 

" Incomplete" ; 

END; 

Disposition  =!>  'JserChannel ; 

AH. User Channel  <- 

CHOPEN(AH.DestID  <-  Assigr.Trar.sactionlD(AH)  = |> 

User  Channel,  "Out",  "Binary"); 

EnQReceiveAlann( AH,  SP); 

END; 
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End  Receive Alarn  <- 

EXPR(SP: Process Hard le , AH: Alarm Handle) 

BESeCL  UserChar.r.el:  User  Data  LIKE  SP.UserQiar-.el; 

DecodeGer.ericCl  ass(AH.Source  Process. Ger.ericaass), 

< Alarn,  Source  Process,  Disposition  XAH)  =,>  UoU-Char.el, 
SIGNAL(AM. Signal) ; 

Free  (AH); 

END; 

StlffR(^%r^e!0UserCnar.r.el :Char.r.elHar.dle,  SP: ProcessHar.dle, 

BEGIN 

DECL  C : Corn B Lock; 

DECL-  CH:  Corn  Handle; 

DECL  Disposition: Reason Code; 

C. Source Process  <-  SP.Name; 

< Cor.r.ID,  Cor.r.Type,  Cor.r.Directicr.,  Cor.r.Bytesizc, 

DestProcess,  Er.dSi3r.al,  Signal,  Doadlir.e  >U)  <.- 
User Channel; 

CorvertTimer (Op , C.  Deadline); 

Dispositior  <-  Reasor.Code  << 

Bl Is Val id Signal ( C . Signal ) #>  "Signal  giver,  is  ir.valid"; 
IsValidHost(C.  DestProcess.  Host)  +> 

"Irvalid  host  address  ir.  process  name  ; 

Assigr.Local  Sccket(C . Local  Socket , SP ) ; 

IsValidBytesizeCC.Cor.nBytesize)  u? 

"Bytesize  giver,  is  invalid”; 

CH  <-  Allocate Cor.r.ectior Handle,  C); 

” Incomplete  , 

END; 

Disposition  =!>  UserChar.r.el; 

Is Abnormal (Disposition)  =>  NOTHING; 

CH0PEN(CH. Source ID  <-  Ass  igr.Trar.s  action  ID  (CH)  = •> 

User Channel,  "Out”,  "Binary”); 
EnQOutputOper.Cor.r(CH,  3P); 

Free(CH) ; 

END; 

End  Open Connection  <-  » 

EXPR(SP:  ProcessHar.dle,  CH:  Conn  Handle) 

BEG  IN 

DECL  UserChanrel -.User Data  LIKE  SP. UserChar.r.el;  _ 

IsAbr.ormaXCH. Dispositior.  <-  OpenDirectCorr.ectior.CCH, 
Er.QOutputCloseCor.r.(CH,  SP); 

< Dispositior.  '''CH)  ==!>  UserChar.r.el; 

SIGNAL (CH. Signal); 

Free(CH) ; 

END; 
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StartCloseCor.rectior.  <- 

EXPR(Op:OpCode,  User  Cham  el : Channel  Handle , SP:  Process  Handle) 
BEGIN 

DECL  C : Corn  Block ; 

DECL  CH: Channel Handle ; 

DECL  Disposition : Reason  Code ; 

< Conn  ID,  DastProcess,  Signal,  Deadline  >(C)  <!  = 

User Channel; 

ConvertTimer(Op,  C. Deadline) ; 

Disposition  <-  Reason Code  << 

BEGIN 

Is ValidSigr.al(C. Signal)  //>  "Signal  giver,  is  invalid"; 
CH  <-  AllocateCChar.r.elHur.dle,  C) ; 

" Incomplete"; 

END; 

Disposition  =!>  UserChar.r.el ; 

IsAbr.ormaKDispositior.)  =>  NOTHING; 

CH. UserChar.r.el  <- 

CHOPEN(CH.  Source  ID  <-  Assigr.Transactior.ID(CH)  =!> 

User  Channel,  "Cut",  "Binary"); 

CH. Source Process  <-  SP.Name; 

EnQOutputCloseCor.r.CCH,  SP); 

END; 

End Close Connection  <- 
EXPR(SP: ProcessHar.dle,  CHiGor.r. Handle) 

BEGIN 

CH. Disposition  <-  CloseDirectCor.r.ectior.CCH,  SP); 

DECL  User  Channel : User  Data  LIKE  3 P.  UserChar.r.el ; 

< Disposition  >(CH)  =!>  UserChar.r.el ; 
FreeLocalSocket(CH,LocalSocket , SP) ; 

SIGNALfCH. Signal); 

CHCL0S3(  UserChar.r.el ) ; 

Free(CH) ; 

END; 

StartTerinir.atior.Sigral  <- 

EXPR( Op: C^>Code , User Charnel  .-Channel Handle , Sn:  ProcessHar.dle) 
BEGIN 

DECL  T:TermBlock; 

DECL  THrTennHar.dle; 

DECL  Disposition:  Reasor.Code; 

TH. Signal  <!=  UserChar.r.el; 

Disposition  <-  Reasor.Code  « 

BEGIN 

IsValidSigr.al(S)  //>  "Signal  giver,  is  invalid"; 

TH  <-  AllocateCTermHar.dle,  T); 

"Incomplete" ; 

END; 

Disposition  =!>  UserChar.r.el; 

IsAbr.or.nal (Disposition)  r>  NOTHING; 

TH. User  Channel  <- 

CHOPEN(NullTrar.sactionID,  "Out",  "Binary"); 

SP. Termination  <-  TH; 

Release(TH); 

END; 


iiTfti  igi^if .4 ....  i.lwEs* 
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ErdTennir.atior.Si^r.al  <- 
EXPR  (SP:  Process  Hard  le , TH:TennHar.dl  X 
BEGIN 

DECL  UserChar.r.el : Channel  Handle  LIKE  SP.  User  Cham  el; 
< Disposition  XSP)  =!>  User  Channel; 

SIGNAL  (TU.Si3r.al); 

CHCLOS  '(UserCnar.r.el) ; 

Free(rH); 

DoStopMe(SP) ; 

END; 

End  Broker.  Correction  <- 

1 

. An  artifact.  Die  correction  has  beer,  broker., 
so  is  closed.  The  Cp  M GoOpMe"  is  posted 
. ar.d  the  CH  delivered  sjch  3 way  as  to 
. post  the  local  proc  Er.d  Signal . ’ */ 

EXPR  (Op  .-Opcode,  SP;  Pi  ^esshar.dle , CH:  Corn  Handle) 

BEGIN 

DECL  UserChar.r.el : User  Lata  LIKE  SP.  UserChar.r.el ; 
SIGNAL(CH.  Fr d Signal ) ; 

CHCLOSE(l’serChar.rel) ; 

Free(CH) ; 

END; 
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DoStopMe  <- 

i 

. Car.cel  all  trar.sactior.s  and  corrections 
. involving  the  user  process.*  V 
EXPK^Dp  :OpCode,  UserChar.rel  ‘.CharrelHar.dle,  SP:  ProcessHar.dle) 
BEGIN 

DECL  SP:  ProcessHar.dle  LIKE  Seize(SP); 
StopTrar.sactiors(SP. OutputMessQ,  SP) ; 

StopTrar. sactior.sCSP. OutputAlarmS,  SP) • 
StopTrarsactior.s(SP. Corrections,  SP) ; 
StopTrarsjctiorsCSP.  Ir.putMessQ,  SP); 

StopTrars3ctiors(SP.  Input  AlarrnQ,  SP); 
StopTrarsacticr.sCSP. R?ceiveMessQ,  SP) ; 
StopTrar.sactiors(SP.  Receive  AlarrnQ,  SP); 

St opTr an  s a c t i or.  s ( S P . C 1 o soCor. r. S , S P ) ; 

DECL  TS: Set (Transaction Hard le ) ; 

Seize(Ger.ericTable) ; 

FOREACH  GH  IN  GenericTable 
DO 

FOREACH  TH  IN  GH. ReceiveMessQ 

DO  TH. Etest Process  = SP.Nsme  ->  Ir.sertCTS,  TH)  END; 

END; 

Release(Ger.ericTable) ; 

StopTrar.sactior.sCTQ,  SP); 

FreeCSP. Termination) ; 

"Normal’'  = !>  UserChar.rel; 

CHCLOSEC  User  Cham  el) ; 

FreeCSP) ; 

END; 

Sto pTr an s actions  <- 
Ev  iUT:ANY,  SP: ProcessHar.dle) 

FOREACH  H IN  T 

DO  Seize(H);  StopTrar sactior.CH,  SP);  Free(H)  END; 

Do  Rescind  <- 

EXPRC  Op:  C^Code,  User  Channel : Channel  Hand  le , SP:  ProcessHar.dle) 
BEGIN 

DECL  Event  .‘Transaction ID; 

Event  <|  = UserChar.rel ; 

DECL  TH: Transact ion Handle  LIKE 
SeizeTrar.sactior.Har.dleC  Event ) ; 

Rescir.dPer.dirgEver.tCTH,  SP)  =!>  TH.  User  Channel; 

Free(TH); 

END; 

Do  Accept Alarms  <- 

EXPR(Op:OpGohp,  User Charnel : Channel. Han  e,  SP: ProcessHar.dle) 

[)  SP.IAccept  <J=  UserChar.rel ; "Normal"  =!>  UserChar.rel  (]; 
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DoResyrch  <-  , , » 

EXPR  (Op : OpCode , UserChar.r.el : Channel  Handle , SP:  ProcessHar.dle) 

BEGir: 

DECL  P: Process Name; 

P <!=  User Channel; 

FOREACH  C IN  SP. Inhibited DestS 

DO  C.Dcvst Process  = P =>  RemoveCC,  SP. Ir.hibitedttestS)  END 
"Normal”  =!>  User Channel; 

END; 

DoWhoAinl  <-  . 

EXPR(Op : Op  Code , UserChar.r.el : Channel  Handle,  SP:  ProcessHar.dle) 

‘ SP. Name  =j>  UserChar.r.el; 
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' SERVERS  • V 

User Call Server  <- 
EXPR(  SQLServer  Hurdle) 

BEGIN 

DECL  Op rOpCode; 

DECL  Wa i t S : Se t ( Ch ar.r. e 1 Hard  1 e ) LIKE  SH. Channels; 

REPEAT 

DECL  UserChar.r.el : Charnel  Handle  LIKE  AWAIT(WaitS) ; 

DECL  SP:  ProcessHar.dle  LIKE  UserCharrel . User  • 

Seize(SP) ; 

Op  <!=  UserCnar.r.el ; 

OpTable[Op](Op,  UserChar.r.el , SP); 

Release(SP) ; 

END; 

END; 

User  Delivery  Server  <- 

t 

! UserDelivery Server  waits  ur.til  it  is  SIGNALed,  ther.  loops  through 
; lts  deiivery  queue,  removes  entries  ar.d  dispatches  to  the 
appropriate  output  routine.  The  entries  are  ther  dequeued. 

’ */ 

E XPR  ( SH : Se  r v er  Ha  r.d  1 e ) 

BEGIN 

DECL  QEntry:Trar.sactior.Har.dle; 

DECL  LP: Process handle ; 

Seize(SH.  Del iveryQ) ; 

REPEAT 

Null (SH. Del iveryQ)  -> 

BEGIN 

SH. Running  <-  FALSE; 

Release (SH. Del iveryQ ) ; 

WAIT( { SH.WakellpSigral  }); 

Seize(SH.teliveryQ); 

END; 

QEr.tr  y <-  Sei  ze(Fror.t(SH.  Del  iveryQ) ) ; 

Release(SH.DeliveryQ) ; 

LP  <-  SeizeProcessHar.dle(Originator  (QEr.try) ) ; 
EndC*)7able[QEntry.Op](LP,  QErtryL 
Release(LP) ; 

Seize(SH. Del iveryQ) ; 

DeQ(SH.  Del  iveryQ,  QEr.try); 

Free(QEr.try) ; 

END; 

END; 
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' Mlscellar.eous  routines  ' */ 

StartGeneric Process  <- 
EXPR  (Class  iGer.ericClassCode;  ProcessHandle) 

BEGIN 

DECL  GH  :Ger.er  icHar.dle  LIKE  Ger.ericTable[Class] ; 

DECL  P: Process Block ; 

P.Name.GerericClass  <-  GH.Coae; 

DECL  PH: Process Handle  LIKE  Allocate! ProcessHandle,  P); 
Complete  Processes  (PH ) ; 

StartUserProcess(GH,  PH); 

PH; 

END; 

Cor.vertTimer  <- 

EXPR (Op: C^Code,  Timer : Integer) 

BEGIN 

Timer  = 0 ->  Timer  <-  TimerDefaults[Op] ; 

Make  Interval  Absa  lu*-e(Timer ) ; 

END; 

Originator  <- 

EXPR(TH transaction  Handle;  Process Name) 

CASECTH.Op] 

[ " Re  c e i v e Gen  e r ic  Mess  ag  e " ] , 

[ H Race  .’.veSpecif  icMess  age'*  ] , 

["ReceiveAlarm"]  r>  TH.Dest Process ; 

TRUE  =>  TH. Source  Process ; 

END; 
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» 


! QUEUE:  Queue  Management  Module  for  MSG 

! 


! Management  routines  for  the  data  base  shared  among  MSG  processes. 

! This  data  base  consists  principally  of  queues  and  sets  of 
! transaction  records.  Each  record  describes  the  state  of  a per.dirg 
! event,  a message,  an  alarm,  or  a direct  connection.  Most  queues 
! and  sets  are  associated  with  particular  local  user  processes, 

! and  are  anchored  in  the  correspond irg  process  handles. 

i 

! Routines  exported  by  QUEIE  are  cal'ed  from  the  servers  that  implement 
! user  process  primitives  (LOCAL),  from  those  that  implement  the 
! MSG- to -MSG  protocol  (REMOTE) , and  from  the  module  CANCEL, 

! which  implements  event  timeouts. 

i 

! The  exports  fall  into  three  groups:  those  dealing  with  messages, 

! alarms,  and  direct  connections. 

j 


! Message  handling  routines: 


! EnQJutputMess 
! Er.QReceiveMess 
! ErQInputMess 
! RecordMESS VOX 
! RecordMESSXREJ 
! RecordMESSNHCLP 
! RecordHOLDVOK 
! RecordM ESSXCANCEL 
! Recorded  IT 
! SendMESSXREJ 
! SendMESSXCANCEL 
! 


SendSpecif icMess , Ser.dGenericMess  primitives 

Receive  Specific  Mess,  ReceiveGer.er  icMess  primitives 

MESS  protocol  item 

MESS-OK  protocol  item 

MESS-RE J protocol  item 

MESS -HOLD  protocol  item 

HOLD-Q K protocol  item 

MESS-CANCEL  protocol  item 

XMIT  protocol  item 

Reject  received  MESS 

Cancel  previously  sent  MESS 


! Alarm  handling  routines: 


! EnQOutpu tnl arm 
! Eh QReceive Alarm 
! EnQIr. put  Alarm 
! RecordALAHMNOK 
! RecordALARMXREJ 
! Ser.dALARMXREJ 


Ser.dAlarm  primitive 
ReceiveAlarm  primitive 
ALARM  protocol  item 
ALARM -OK  protocol  item 
ALARM' RFJ  protocol  iten 
Reject  received  ALARM 


Connection  handling  routines: 


! 

! Er.QOutput  Open  Corn 
! ErQOutputCloseConn 
! EnQIn  put  Open  Conn 
' ErQIr.putCloseCorr 
! RecordCONNNREJ 
! Send CONN \ RE J 
l 


Open  Corn  primitive 

CloseCor.r  primitive 

CONN-OPEN  protocol  item 

CONN-CLOSE  protocol  item 

CCNN-RSJ  protocol  item 

Reject  received  CONN-OPEN  or  CONN-CLOSE 


’ */ 
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! Conventions  observed  ir.  this  module: 
! Local  variables  are  declared  by 


<rame>  ==  Cnode> 

j or  <r.ame>  <==  <iritial  valuc> 

! These  are  equivalent  to 

! DECL  <r.a-ne> : <mode> 

! and  DECL  <name>:ANY  BYVAL  <ir.itial  value> 

! respectively. 


! Whenever  a shareable  record  (e.g. 
! is  passed  to  a QUEUE  routine,  it 
• lock^  ("Seized)  the  record,  if 
! for  unlocking  it. 


> 3 MessHar.dle  or  a ProcessHar.dle) 
is  assuned  that  the  caller  has 
necessary,  and  will  be  responsible 
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t 


Message  Handling 


' V 


Er.OOutputMsss  <- 

1 

! M is  ar.  outgoing  Mess  fron  user  process  SP. 

! Charge  SP  for  the  text  buffer  space  used  by  M. 

! Divide  Messes  into  two  categories: 

! (1)  those  havig  specific  destir.aticr.  hosts,  ar.d 

! (2)  generic  .nesses  that  are  host-less. 

! If  M is  host-less,  obtain  a trial  host  ar.d  use  Er.QHostSpecif icMess 
! to  try  to  deliver  M.  If  M is  rejected  by  the  chosen  hast, 

! RecordMESSNREJ  will  select  a new  host  and  use  Ser.dHostSpecif icMess 
! to  serA.  it  again. 

i 

• */ 

EXPR(M:MessHar.dle , SP:  ProcessHar.dle) 

BEGIN 

DebitBufferCSP,  M); 

M. IsGer.eric  AND  NulHM.Dest  Process.  Host)  -> 

BEGIN 

M.IsHostLess  <-  TRUE; 

M.DestProcess .Host  <-  GetNewGer.ericHost(M) ; 

END ; 

StartTinir.g(M) ; 

Er.QHostSpecificMessCM,  SP); 

END; 


GetNewGer.ericHost  <- 

» 

! Find  a destination  host  for  M appropriate  to  its  generic  category. 
! If  its  destination  host  is  null,  take  the  first  possible  host, 

! otherwise  take  the  successor  of  the  present  host . Return  a null 
! host  code  if  the  present  ho*t  is  the  last  in  the  list. 

! 

1 V 

EXPR  (M : Mess  Hand  le ; HostCode) 

BEGIN 

OldHost  <==  M. Dest Process. Host ; 

GH  <==  GenericTable[M.DestProcess.GenericNane] ; 

Null (OldHost)  =>  First(GH. HostS); 

Next(GH. Hosts,  OldHost); 

END; 
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ErQHostSpecif  j.cMess  <- 

i 

• Check  M for  special  har.dlir.’  requirensr.ts.  If  it  is  a sequenced  or 
! stream-marked  message,  check  for  prior  Messes  that  inhibit 

! transmission  ^f  M.  A sequenced  message  must  be  held  until  all 
! previous  sequenced  Messesto  the  sane  destination  have  been 
! acknowledged.  A stream-marked  Mess  must  wait  for  all  prior  Messrs 
! to  the  S3me  destination  to  complete. 

9 */ 

EXPR(M:Me3sHar die,  SP: ProcessUardle) 

BEGIN 

PostporeTrar.smissior.  <-=  FALSE; 

FQREACH  PriorM  IN  SP. Output MessQ 
DO 

PriorM.DestProcess  - M. Dost  Process  AND 
(PriorM. Is  Marked  OR  M.IsMarked  OR 
M.  IsSequer.ced  AND  PriorM,  IsSequer.ced)  => 
Postpor.eTrar.smission  <-  TRUE; 

END; 

EnQCSP.CtitputMessQ,  M)  ; 
fbstponeTrar.snission  => 

M. State  <-  "Awaiting  prior  MESS  completion" ; 
SerdifostSpecificMess(M,  SP); 

END; 

SenuHostSpecificMess  <- 

» 

J *£  destination  is  a local  process,  pass  a copy  of  M directly  to  the 
! handler  for  received  Messes. 

! Otherwise,  it  must  go  out  on  the  net 'work.  Decide,  based  or.  current 
! buffer  space  for  SP,  whether  to  offer  to  hold  the  Mess,  to  warn 
! that  a hold  will  be  impossible,  or  neither.  Deliver  it  to  the  server 
! for  the  destination  host. 

i 

• */ 

EXPR(M: MessHandle , SP: Process Handle) 

BEGIN 

M.Dest Process.  Ibs t = LocalHcst  => 

BEGIN 

InputM  <==  CopyMessHar.dle(M) ; 

PnQInputMessdr.putM,  SP); 

Free( InputM) ; 

END; 

M.HoldOk  <-  SP.FreeBufferSi ze  GE  Ho Id Ok Threshold; 

M. No Ho Id  <-  SP.FreeBufferSize  LT  No  Ho  Id  Threshold; 

M. State  <-  "Awaiting  MESS-OK"; 

SendMESS(M) ; 

END; 
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i 

! DP  is  to  be  the  destination  of  a message,  for  which  it  is  issuing 
! a ReeeiveMess  conmar.d. 

! Input  generic  Messes  and  ReceiveGer.ericMess  events  are  queued  in  the 
! appropriate  Ger.ericTable  entry.  Therefore  define  DH  to  be  either  DP 
! itself,  if  RM  is  specific,  or  the  appropriate  GenericHar.dle,  if  RM 
! represents  a ReceiveGer.ericMess. 

! If  there  are  any  queued  input  Messes  at  DH  that  are  complete  with 
! text  (either  accepted  Messes  or  ones  held  by  a local  sender),  take  on 
! merge  it  with  RM , and  deliver  it  to  DP. 

! Otherwise,  enqueue  RM  in  DHs  ReceiveMessQ,  and  start  timing  on  RM, 

! using  the  interval  supplied  by  the  user  process  DP. 

i 

1 */ 

EXPR(RM: Mess handle,  DP: Process Handle) 

BEGIN 

MR  ==  Mess Handle; 

DH  <=  = 

BEGIN 

NOT  RM.IsGer.eric  =>  DP; 

DECL  GH: Generic Handle  LIKE 
Ger.er  icTable[DP.  Name . Gen  er  ic  Nam  e ] ; 

REPEAT  TestSeize(GH)  =>  GH;  Pause (SeizeWait)  END; 

END; 

BEGIN 

FOREACH  M AT  MLocatior.  FromFrontOf  DP.  Ir.putMessQ 
DO 

NOT  Null(M.Text)  => 

[)  MR  <-  M;  Seize(MR);  DeQAt( MLocatior.)  (]; 

END; 

NOT  Null (MR)  => 

BEGIN 

StopTiming(MR) ; 

MR. Source Process. Host  = LocalHost  -> 

Local X,1IT(MR,  DH); 

MergeMessHar.dles(RM , MR) ; 

Free(MR) ; 

RM. Disposition  <-  ’’Normal'’; 

Deliver(RM,  DP); 

CreditBuffer(DH,  RM); 

END; 

EnQ(DH. ReceiveMessQ,  RM); 

RM. State  <-  ’’Awaiting  MESS”; 

StartTimir.g(RM) ; 

END; 

RM.IsGeneric  ->  Release(DH); 

~ND; 
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Local XM IT  <- 

t 

! M represents  3 local  Mess  transaction.  M has  been  held  in  the 
! source  process  (3P)  queue.  Now  it  is  to  be  ’’transmitted”  to  the 
! destination  (DH),  simulating  a network  XMIT  followed  by  a MESS 
! retransmission. 

! Debit  DU  and  credit  SP  for  the  text  buffer  space. 

! Complete  the  transaction  for  the  sender  by  accepting  the  message. 

i 

• V 

E XPR  ( M : Mes  s Ha  r.  d 1 e , DH:I>3St Handle) 

BEGIN 

SP  <-=  SeizeProcessHar.dle(M.SourceProcess) ; 

DebitBuffer(DH,  M); 

CreditBuffer(SP,  M); 

AcceptMess(M,  SP); 

Release(SP); 

END; 

RequestTransmissior.  <- 

t 

! M represents  a Mess  to  DH  that  is  being  held  by  its  sender, 

! but  is  now  to  be  retransmitted. 

! If  the  sender  is  renote,  send  it  an  IT  item. 

! Otherwise,  use  LocalXMIT 

! 

1 */ 

EXPR(M:MesslIar.dle,  DH:DestHandle) 

BEGIN 

M. Source  Process. Host  = LocalHost  =>  LocalXMIT(M,  DH); 
SendXMIT(M); 

CommitBuffer(DH,  M); 

END; 


» 
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EnQIrputMess  <- 

» 

! The  negation  of  M.QWait  is  ORed  into  M.  No  Mold  ir.  case  M is  generic. 

! Thus  M.NoHold  indicates  refusal  to  hold  M at  the  source,  for  whatever 
! reason . 

I Input  Messes  are  distirguished  as  "old”  (those  sent  in  response 
! to  an  XMT  request)  or  "new".  Old  Messes  are  recognized  by  their 
! not. -null  destination  IDs. 

! (SP  represents  the  sender  of  M,  if  the  sender  is  local.) 

t 

• */ 

EXPR(M:  Mess  Handle  , 3P:  ProcessHar.dle) 

BEGIN 

M. No Hold  <-  M. No Ho Id  OR  NOT  M.QWait; 

NOT  Null(M.DestlD)  =>  Er.QOldlnputMess(M) ; 

EhQNewIr.putMess(M,  SP); 

END; 


Er.QNewIr.putMess  <- 

» 

! NewM  is  a newly  received  Mess. 

! SP  is  the  sender  of  NewM,  if  local.  Otherwise,  SP  is  null. 

! Define  DH  to  be  the  destination  process  handle  (if  NewM  is  specifically 
! addressed)  or  the  appropriate  generic  class  handle  (if  NewM  is  generic). 
! In  the  latter  case,  if  there  is  r.o  process  with  a pending  Receive- 
! GenericMess  primitive,  try  to  start  a new  process  of  the  right  class. 

! Ehqueue  NewM  in  DH. Ir.putMessQ  if  there  is  room. 

! Assign  a local  transaction  ID  for  future  reference. 

! Decide  whether  to  deliver  NewM,  to  accept  it  pending  a local  Receive, 

! to  ask  the  sender  to  hold  it,  or  to  reject  it. 

i 

' */ 

EXPR(  NewM:  Mess  Handle , SP:  ProcessHar.dle) 

BEGIN 

DH  <==  SeizeDest Handle (NewM. Dest Process ) ; 

Null(DH)  => 

Reject Mess (NewM, 

BEGIN 

NewM. Is Generic  => 

"That  generic  class  not  supported  here"; 

"Destination  process  unknown"; 

END,  SP); 

BEGIN 

Null(DH. ReceiveMessQ)  AND  NewM. IsGer eric  -> 
StartGenericProcess(DH.Gode) ; 

IsFuilQ(DH.  Ir.putMessQ)  => 

Reject Mess (NewM, 

"Insufficient  resources  to  complete  command", 

SP); 

EnQ(DH.  Ir.putMessQ,  NewM)  ■ 

NewM.DestID  <-  AssignTransactionlD(NewM) ; 
AcceptHoldOrRejectMess(NewM,  DH,  SP); 

END; 

Release(DH) ; 
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END; 
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Er.QQldlnputMess  <- 

» 

! NewM  has  beer,  sent  ir  response  to  an  X>1  IT . 

! Use  NewMs  destir.atior.  ID  to  fir.d  the  original  Mess Handle  (OldM). 

! If  r.ore  car  be  found,  or  if  OldM  is  the  wrong  transaction,  simply 
! treat  NewM  as  a new  incoming  Mess.  (The  original  could  have  timed  out.) 
! Otherwise,  merge  NewM  into  OldM,  copying  the  Text.  HoldOk,  and 
! NoHold  fields,  among  others. 

! Let  DH  be  the  destination  of  OldM. 

! Decide  how  to  dispose  of  OldM  using  the  same  algorithm  as  for 
! new  input  Messes. 

» 

; */ 

EXPiU  NewM:  Mess  Handle) 

BEGIN 

OldM  <==  SeizeTransaction(NewM.DestlD) ; 

BEGIN 

Null  (OldM)  OR  NOr  IsMessIlar.dle'OldM)  OR 
NOT  Va  1 id  XM  IT  Re  s par.  s o ( Ne  wM , OldM)  => 

Er  QNe  w Ir.  pu  t Mes  s ( Ne  wM ) ; 

StopTimirg(OldM) ; 

MergeMessH3rdles(01 dM,  NewM) ; 

DH  <=  SeizeD?stHandle(01dM. DestProcess) ; 

RemitBuffer(Dli,  M); 

AeceptHoldORejectM?ss(QldM,  DH); 

Release(DH) ; 

END; 

Release(OldM) ; 

END; 

Val  idXMITRespon.se  <- 

EXPRCNewMiMessHardle,  01dM:MessHar.dle;  300L) 

OldM. State  = "Awaiting  retransmission"  AND 
NewM.  Source Process  = OldM. Source  Process  AND 
NewM. Dest Process  = OldM. Dest Process  AND 
NewM.SourcelD  = OldM.SourcelD; 


» 
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AcceptHoldOrRejectMess  <- 

» 

! M is  ar.  ir.put  Mess  for  destination  DH,  which  is  either  a Ger.ericHar.dle 
! (if  M is  generic)  or  a Process  Handle  (if  M is  specific). 

! SP  is  the  sending  process,  if  local  to  this  host;  otherwise  null. 

! M has  beer,  entered  in  DH.  InputMessQ. 

! Possible  outcones: 

! M will  be  accepted  and  delivered. 

! M will  be  accepted  and  queued. 

! The  sender  will  be  asked  to  buffer  M and  retransmit  later. 

! M will  be  rejected. 

! If  the  Text  of  M has  been  omitted  for  lack  of  sufficient  temporary 
! buffer  space,  then  either  request  hold  or  reject. 

! Else  if  a matching  Receive  Mess  primitive  is  pending,  accept  and 
! deliver  M. 

! Else  if  buffer  space  pernits,  accept  M and  leave  it  queue  pending 
! the  executior.  of  a local  ReceiveMess  primitive. 

! Otherwise,  eitner  reject  M or  request  that  the  sender  hold  it. 

! 

’ */ 

EXPR(M:MessHandle.  DH:DestHar.dle,  SP: ProcessHar.dle) 

BEGIN 

Null (M. Tex t)  =>  HoldOrRejectMess(M,  DH,  SP); 

RM  <==  SeizeMatchirgReceiveMess(M,  DH); 

NOT  Null ( RM ) => 

BEGIN 

StopTimir.g(RM)  ; 

DeQ(DH. InputMessQ,  M); 

MergeMessHar.dles(RM,  M); 

AcceptMess(M,  SP); 

BEGIN 

NOT  RM.IsGer.eric  =>  Deliver(RM,  DH); 

DP  <==  Se izeProcessHar.dle(RM.Dest Process ) ; 

Deliver(M,  DP); 

Release(DP) ; 

END; 

Release(RM) ; 

END; 

NOT  RoomToAccept(M,  DH)  =>  HoldOrRejectMess(M,  DH,  SP); 
AcceptMess(M,  SP); 

DebitBuffer(DH,  M); 

M. State  <-  "Awaiting  ReceiveMess"; 

StartTimir.g(M,  Awaitir.gReceivelrterval) ; 

END; 
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HoldORajectMess  <- 
{ Sp\fsMthe  Irdi!? 

; *hf  beer.  er.teredPirCDHSlnpuft,S. t0  thiS  h°St:  0thsrwiS9  r.ull. 

I ~ - *»* 

! trar.sfer.  - -0Joh  bjffer  space,  otherwise  abort  the 

i »' LTrVLTStlzX'*"'  tht  ««*•>  «*W  <*«*«.. 

have  done  so.)  record,  the  calling  path  will  already 


! 0therwise-  ser-d  3 MtSS -HOLD  to  the  sender  of  M. 


E)BEGIN','SSHar'dle’  DH;DestH3r-dle,  SP:  ProcessHar.dle) 

M.NoHold  => 

BEGIN 

DeQCDH.Ir.putMessQ,  M): 

RejectMess(M, 

^Insufficient  resources  to  complete  command", 

END; 

NOT  Null(SP)  => 

BECIN 

NOT  RooinToHcld(SP,  M)  => 

BEGIN 

CfeQ(DH.  Ir.putMessQ,  M); 

RejectMess(M, 

^Insufficient  resources  to  complete  command" , 

END; 

SouroeM  <zr  LookupTrarsactior.(M.SaurcelD)- 
SourceM. State  <-  "Awaiting  XdlT";  ' 

M. State  <-  "Held  by  sender"; 

^StartTmr.gW,  AwaitirSFr3eBuffer Interval ) ; 

M.Text  <-  Null Text; 

Ser.dMESS\HOLD(M) ; 

BEGIN 

M. State  <-  "Held  by  sender"; 

END;artTL,nlr'S(M’  AwaitirSFree&jffer Interval); 

~:St?£e  <*  "Awaiting  HOLD-OK"; 

END;  tTlrnlrg(M’  AwaitirgHOLD\OKIr.terval) ; 
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SeizeMatchir.gRaceiveMess  <- 

t 

! M is  an  incoming  Mess  for  DH. 

! If  DH  has  a pending  Receive  that  will  match  M, 
! seize,  dequeue,  and  return  it. 

! Else,  return  nil. 

i 

» */ 

EXPR(M:MassHar.dle,  DH: Dost Handle ; MessHar.dle) 
BEGIN 

Null (DH. Race iveMessQ)  =>  NullMessHandle ; 

RM  <==  Fror.t(DH.  ReceiveMessQ) ; 

Seize(RM) ; 

DeQ(DH.  ReceiveMessQ) ; 

RM; 

END; 


SeizeDestHar.dle  <- 

» 

! Return  a suitable  destination  handle  for  the  given  process  name  P. 

! If  P is  a generic  name,  and  its  class  is  supported  on  the  local  host, 
! return  the  corresponding  generic  hardle. 

! If  P is  a valid  specific  process,  return  its  handle. 

! Otherwise,  return  a null  handle. 

i 

’’  */ 

EXPR(P: ProcessName;  Dest Handle) 

BEGIN 

NOT  Null (P.  Ir.star.ee)  =>  Seize ProcessHar.dle(P) ; 

DH  <==  Ger.ericTable[P.  Name.  Generic  Name  ] ; 

REPEAT  TestSeize(DH)  =>  NOTHING;  Pause(SeizeWait)  END; 

NOT  DH. Ur. supported  =>  DH; 

Release (DH) ; 

Null  DestHar.  die; 

END; 

MergeMessHardles  <- 

» 

! M represents  a newly  received  Mess. 

! RM  is  either  a ReceiveMess  record  or  the  result  of  an  earlier 
! transmission  of  M. 

! Copy  the  Text  of  M into  RM,  as  well  as  other  fields  which  might 
! be  different  on  retransmission. 

! 

* V 

EXPR(RM:  Mess  Handle,  M:  MessHar.dle) 

BEGIN 

RM. No Hold  <-  M. No Hold ; 

RM.  Ho  Id  Ok  <-  M.HoldOk ; 

RM. Source Process  <-  M. Source Process ; 

RM.  Text  Length  <-  M.TextLer.gth; 

RM.Text  <-  M.Text; 
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AcceptMess  <- 

i 

! If  SP  is  nor. -null,  then  M represents  ar.  irtrahost  Mess  and  S?  is 
! the  -source  process.  In  that  case,  simulate  a MESS -OK  acknowledgement 
! of  M for  SP.  (It  is  unnecessary  to  seize  the  original 
! MessHar.dle.  The  callirg  path  has  it  locked.) 

! Otherwise,  send  a MESS-OK  to  the  remote  source  of  M. 

! 

' */ 

EXPR (M : MessHar.dle , SP: ProcessHandle) 

BEGIN 

Null(SP)  =>  Ser.dMESS\OK(M) ; 

AcceptQjtputMess(LookupTransaction(M.SourceID) , SP); 

END; 


RejectMess  <- 

i 

! If  SP  is  non-null,  then  M represents  an  ir.trahost  Mess  and  SP  is 
! the  source  process.  In  that  case,  simulate  a MESS-REJ  acknowledgement 
! of  M for  SP.  (It  is  unnecessary  to  seize  the  original 
! MessHar.dle.  Ihe  calling  path  has  it  locked.) 

! Otherwise,  send  a MESS-REJ  to  the  remote  source  of  M. 

! 

’ */ 

EXPR(M:  MessHar.dle,  Reason:  Rea  son  Code,  SP:  ProcessHandle) 

BEGIN 

Null(SP)  =>  Ser.dMESS\REJ(M,  Reason); 
Reject(XjtputMess(LookuDTransaction(M.SourceID) , Reason, 

SP); 

END; 

CancelMess  <- 

! M is  an  outgoing  Mess  from  SP  that  is  awaiting  XMIT,  but  must  be 
! canceled  for  lack  of  buffer  space. 

! If  the  destination  is  local,  simulate  receipt  of  a MESS-CANCEL  by 
! the  destination.  Otherwise,  send  a real  MESS-CANCEL  on  the  network. 

! Then  abort  the  Ser.dM ess  primitive  of  SP. 

t 

' */ 

EXPR(M:MessHandle,  SP: ProcessHandle) 

BEGIN 

M. Reason  <-  "Insufficient  resources  to  complete  command"; 

BEGIN 

M.Dest  Process. Host  = LocalHost  => 

RecordMESSXCANCEL (Value ( M) ) ; 

SendMESSX CANCEL ( M , M. Reason) ; 

END; 

Reject(XitputMess(M,  M. Reason,  SP); 

END; 
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RecordMESSXOK  <- 

i 

! A MESS-OK  has  come  ir.  for  MOK.  Source  Process.  If  r.o  corresponding 
! transaction  can  be  found,  simply  do  nothing.  Otherwise,  complete 
! the  designated  pending  event. 

t 

’ V 

EXPR(M0K: Mess Block) 

BEGIN 

OldM  <==  Seize  l>ansaction(MOK. SourcelD) ; 

Null(OldM)  OR  MessMismatch(01dM,  MOK)  r> 

/*  ’Could  have  timed  out’; 

OldM. State  //  "Awaiting  MESS-OK”  => 

MSGError( 'MESS-OK  received  in  wrong  state’); 

SP  <=  Seize ProcessHar.dle( MOK.  SourceProcess) ; 
AcceptOutputMessCOldM,  SP); 

Release (OldM) ; 

Release(SP) ; 

END; 

RecordMESSXREJ  <- 

i 

! A MESS-RE J has  come  in  for  MR. SourceProcess.  If  no  corresponding 
! transaction  can  be  found,  simply  do  nothirg.  Otherwise,  abort 
! the  designated  pending  event,  giving  MR. Reason  as  the  error  code. 

! 

• V 

EXPR(MR.-MessBlock) 

BEGIN 

OldM  <==  SeizeTransactior.(MR.SourcelD); 

Null (OldM)  OR  Mess Mismatch (OldM , MR)  => 

/*  ’Could  have  timed  out’; 

SP  <=  SeizeProcessHar.dle(MR.  SourceProcess) ; 
Reject0utputMess(01dM,  MR. Reason.  SP); 

Release(OldM) ; 

Release(SP) ; 

END; 


* 
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AcceptOutputMess  <- 

t 

! M,  a Mess  ser.t  by  SP,  has  beer  accepted  at  its  destination. 

• Complete  M,  ar.d  trar.snit  ary  subsequent  Messes  from  SP  to  M.Dest Process 
! that  may  have  beer  blocked  pending  acknowledgement  of  M. 

! Scan  SPs  queue  of  output  Messes  from  least  recent  to  most  recent. 

! Ignore  Messes  to  other  destir atior.s. 

! When  M is  found,  delete  it  from  the  queue,  but  continue  to  scan 
! for  later  Messes,.  QM,  which  ure  waiting  to  be  sent. 

! If  QM  is  found,  and  is  marked,  terminate  the  search,  and  send  it  if 
! removal  of  M has  unblocked  it.  Ary  later  Messes  remain  blocked  by  QM. 

! If  QM  exists  and  is  sequenced,  its  treatmert  deperds  on  M. Handling: 

! If  M. Is  Sequenced , QM  must  now  be  unblocked.  Send  QM  and  stop  scanning. 
! If  M.IsMarked,  send  QM  if  it  is  now  unblocked,  but  continue  to  scan 
! for  newly  unblocked  Messes. 

! Otherwise,  simply  terminate  the  scan:  removal  of  M has  not  unblocked 
! QM,  and  any  later  Messes  that  might  have  beer,  blocked  by  M are 
! also  blocked  by  QM. 

! After  the  scan,  copy  the  destination  process  name  into  M in  case  it 
! was  a generic  Mess,  deliver  M to  SP,  and  credit  SP  with  the  space 
! being  freed. 

! 

• */ 

EXPRCM: Mess Har die , SF: Process Handle) 

BEGIN 

MFound  <==  FALSE; 

PriorMesses  <==  FALSE; 

Prior Sequer.cedMesses  <==  FALSE; 

Termir.ateScan  <==  FALSE; 

FOREACH  GM  AT  QMLocation  FromFror.tOf  SP.OutputMessQ 
DO 

MatchirgProcessNamesCQM.  Dest  Process , M.Dest  Process)  -> 

BEGIN 

NOT  MFound  => 

BEGIN 

QM  //  M =>  PriorMesses  <-  TRUE; 

MFound  <-  TRUE; 

StopTLmir.g(M) ; 

DeQAt( QMLocation) ; 

END; 

QM. State  //  " Awaiting  prior  MESS  completion”  => 

PriorMesses  <-  TRUE; 

QM.IsMarked  => 

BEGIN 

NOT  PriorMesses  -> 

SendBostSpecificMess(QM,  SP); 

Termir.ateScan  <-  TRUE; 

END; 
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QM.  IsSequer.ced  => 

BEGIN 

M. Is Sequenced  => 

BEGIN 

Ser.dHostSpecif  icMess(QM) ; 

Termir.ateScan  <-  TRUE; 

END; 

NOT  M.IsMarked  =>  Terminate  Scar.  <-  TRUE; 

PriorSequer.cedMesses  => 

/*  'QM  remains  blocked'; 

Ser.dHostSpecif  icMess(QM) ; 

PriorMesses  <-  Prior Sequer.cedMesses  <-  TRUE; 

END; 

ASSERTCM. IsMarked)  /*  ' QM  cart  be  blocked  by  a marked  Mess 

! between  QM  ard  M or  else  the  scan 
! v/auld  have  terminated  by  now.  '; 
Send HostSpeci ficMes s( DM,  SP) ; 

PriorMesses  <-  TRUE; 

END; 

Termir.ateScan  => 

/*  'Later  blocked  messes  remain  blocked'; 

END; 

M. Disposition  <-  "Normal"; 

M.Dest Process  <-  DestProcess; 

Deliver(M,  SP); 

CreditBuffer(SP,  M); 

END; 
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RejectOutputMess  <- 

» 

! Purpose: 

! A Mess  M from  SP  has  beer,  rejected  by  M.  Dost  Process.  If  M was  origir.ally 
! a generic  Mess  without  a specified  destination  host,  try  to  find  an 
! alternate  host  for  it.  If  successful,  send  it  out  again.  Otherwise, 

! abort  M,  and  either  abort  or  transmit  subsequent  Messes  from  SP 
! to  M.Dest Process  that  have  been  blocked  pending  acknowledgement  of  M. 

! Method: 

! Scan  SPs  queue  of  output  Messes  from  least  recent  to  most  recert. 

! Ignore  Messes  to  other  destinations. 

! When  the  Mess  M correspond  r.g  to  SourcelD  is  found,  either  (1)  send  it  to 
! a new  host  (if  it  was  originally  hostless),  or  (2)  abort  M, 

! but  cortir.ue  to  scan  for  later  Messes,  QM,  which  are  blocked 
! pending  completion  of  earlier  ones. 

! If  such  a QM  is  found,  treat  it  as  follows: 

! If  M.Isftsrked,  all  subsequent  Messes  are  to  be  aborted,  so  abort  QM. 

! Else  if  QM.IsMarked,  it  may  now  be  unblocked.  If  so,  send  it. 

! Else  if  both  M and  QM  are  sequenced,  abort  QM;  all  sequenced  Messes 

! subsequent  to  M will  be  aborted  until  the  user  process  Resyr.chs. 

! Otherwise,  M was  not  blocking  QM,  so  it  remairs  blocked. 

! If  M has  no  special  handling,  the  scan  can  be  terminated  after  the  first 
! such  QM  has  beer.  seen. 

! No  Deliver  will  be  TRUE  iff  SP  is  terminating;  dor.t  deliver  anything  to  it 

• V 

EXPR(M:MessHardle , 

Reason : Reason  Code , 

SP:  ProcessHar.dle, 

NoDeliver :B00L) 

BEGIN 

MFour.d  <==  FALSE; 

PriorMesses  <==  FALSE; 

Termir.ateScar.  <==  FALSE; 

FOREACH  QM  AT  QMLocatior.  FromFrortOf  SP.&itputMessQ 
DO 

Matchir.gProcessNames(QM.Dest Process,  DestProcess)  -> 

BEGIN 

NOT  MFound  => 

BEGIN 

QM  //  M =>  PriorMesses  <-  TRUE; 

MFour.d  <-  TRUE; 

NOT  M.IsHostLess  => 

AbortMsssCM,  QMLocatior,  SP,  Reason); 

M.Dest Process. Host  <-  GetNewGenericHost(M) ; 

Null (M.Dest Process.  Bast)  => 

AbortMess(M,  QMLocatior,  SP, 

"Refused  by  all  suitable  hosts”); 
SendHostSpecificMess(M,  SP); 

TermirateScan  <-  TRUE; 

END; 
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QW. State  S "Awaitirg  prior  MESS  completion"  = > 
PriorMesses  <-  TRUE; 

M.  Is  Marked  =>  t . r op 

*r.„  grt*  •«««•> 

Terminate  Scar.  <-  M.  Handling  - Atonal  , 

QU.IsMarkei  :> 

BEGIN 

NOT-  PriorMesses  -> 

Ser.dibstSpacificMessCQM, 

PriorMesses  <-  TRITE; 

NOT  (QM.IsSequer.cei  AND  'V^aslrtlSockirg  (W'! 
ASSERT  (PriorMesses)  /*  MS™ 

AbortNtess(QM,  .^Location, ^ messa3e"); 

END; 

.«=«  ™«it.  M#> 

END; 


END: 


AbortMess  <- 

EXPR(M:MessHardle  , 

QP:  Queue  Er.try  Pointer , 

SP:  Processlbr.dle, 

Reason : Re a son Code > 

No Deliver: BOOL) 

BEGIN 

StopTinir^CM) ; 

DeQAt(QP); 

M. Disposition  <-  Reason; 
CreditBufferCSP,  M); 

M.Text  <-  NullText; 

NOT  NoDeliver  ->  DeliverCM, 
END; 


SP); 
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RecordMESSVlOLD  <- 

f 

! A MESS -HOLD  item  has  arrived. 

! Look  for  the  transaction,  OldM,  designated.  If  it  cart  be  found,  send  a 
! MESS-CANCEL.  OldM  may  have  timed  out  or  been  Resoirdel. 
t Check  for  correct  transaction  state. 

! See  whether  there  is  room  to  hold  OldM.  If  not,  serd  MESS-CANCEL, 
t If  so,  send  HOLDXOK,  unless  that  was  implicit  in  the  original  MESS 
! transmission. 

i 

’ V 

EXPR(MH: Mess Block) 

BEGIN 

OldM  <==  SeizeTrarsactiorCMH. SourcelD) ; 

Null (OldM)  => 

Ar.swerBelateditemCMH,  "MESS-CANCEL" , 

"Destination  process  unknown") ; 

BEGIN 

IsMessHar.dle(OldM)  AND  Mull  (OldM.  DestID)  -> 

OldM.  DestID  <-  MH.DestID; 

Me  a s Mi  sm  a tc  h ( Old  M , MH)  => 

MSGError( 'Transaction  misnatch'); 

OldM. State  //  "Awaiting  MESS-OX"  => 

MSGError( 'MESS -HOLD  received  in  wrong  state’); 

0?  <==  SeizeProcessHardle(OL!M.SourceProcess) ; 

BEGIN 

SP.  FreeBufferSize  GE  MirMessHoldThreshold  => 

BEGIN 

01JM. State  <-  "Awaiting  XMIT"; 

NOT  CdviM.  HoldCk  ->  Send  HOLDXOK  (OldM) ; 

END; 

RejectOutputM?~s(SP,  OldM. SeurcelD,  OldM. Dest Process , 

"Insufficient  resources  to  complete  command"); 
Ser.dMESSX  CANCEL  ( 01  « 

"Ir.sufficier.t  resources  to  complete  command"); 

END; 

Release(SP) ; 

END; 

Release(OldM) ; 

END; 
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RscordHOLDYOK  <- 

» 

! A HOLDXOK  item  has  arrived. 

! If  the  designated  transaction  has  timed  out,  invite  the  sender  to 
! re transmit  (XMIT). 

! Otherwise,  be  sure  that  HOLDYOK  is  expected. 

! Let  DH  denote  the  destir  atior.,  whether  generic  or  specific. 

! If  DH  now  has  roam  for  the  Mess,  request  retransmission  by  sending  XdlT. 
! Otherwise,  lea^e  the  transaction  in  the  "Held  by  sende-"  state,  waiting 
! for  buffer  space  to  become  available. 

i 

' */ 

EXPR(HOK:MessBiock) 

BEGIN 

OldM  <==  SeizeTrar.sactionCHQK.  DestID) ; 

Null(OldM)  =>  Ar.swerBelatedltemCHOK,  ")MIT"); 

BEGIN 

MessMismatchCOldM,  HOK)  => 

M$GError( 'Transaction  mismatch’ ) ; 

OldM. State  //  "Awaiting  HOLD-OX"  => 

MSGErrorC 'HOLD-OX  ir  wrong  state'); 

StopTimir.g(OldM); 

DH  <==  SeizeDestHar.dleCOldM.  DestProcess) ; 

BEGIN 

DH.FreeBufferSize  GE  X'UTThreshold  => 

BEGIN 

OldM. State  <-  "Awaiting  retransmission"; 

StartTLmir.gCOldM,  Awaitir.gRetrar.smissior. Interval ) ; 

Send XM IT (OldM) ; 

END; 

OldM. State  <-  "Held  by  sender"; 

StartTLmir.gCOldM,  AwaitirgFreeBuffer Interval) ; 

END; 

Release(DH); 

END; 

Release(OldM) ; 

END; 


Abstract  Model  of  MSG 
todule  QUEUE 


99 


RecordMESSXCANCEL  <- 

» 

! A MESS\C ANGEL  item  has  arrived. 

! If  the  transaction  it  designates  does  r.ot  exist,  just  ignore  it. 

! Check  the  validity  of  the  transaction  state,  then  delete  its  record  from 
! the  approcriate  Ir.  put  Mess  Q. 

i 

; V 

EXPR(MC:MessBlock) 

BEGIN 

OldM  <=  SeizeTrarsaction(MC.DestlD); 

Null (OldM)  =>  /*  ’Ignore  belated  MESS-CANCEL’; 

BEGIN 

Mess Mi  snatch (OldM,  MC)  => 

MSGSrror( 'Transaction  mismatch' ) ; 

OldM. State  if  "Awaitirg  HOLD-OK”  AND 
OldM. State  if  "B>ld  by  sender"  AND 
OldM. State  if  "Awaiting  retransmission"  => 

MSGError( 'MESS-CANCEL  received  ir  wrorg  state'); 

StopTimir.g(CldM) ; 

DH  <==  SeizeDestHar.dle(OldM.DestProcess) ; 

DeQ(DH.In?utMessQ,  OldM); 

Free(OldM) ; 

Re  lease (DH) ; 

END; 

Release (OldM) ; 

END; 


- ’• 


Abstract  t-bdel  of  MSG 
Module  QUEUE 


Record  XM  IT  <_ 

* 

! Ar.  MIT  request  has  arrived. 

! If  the  designated  transaction  has  timed  out,  MESS-CANCEL  will  already 
! have  beer,  sent,  50  ignore  the  X-1IT. 

! Otherwise,  after  checking  the  transaction  state,  retransnit  the  held  Mess 

' */ 

EXPR(XM:  Mess  Block)  . 

BEGIN 

CldM  <=  = SeizeTransaction(XM.SrurceTD) ; 

Null(OldM)  =>  /*  'Ignore  belated  MIT'; 

BEGIN 

MessMismatch(01dM,  XM)  => 

MSGError( 'Transaction  mismatch’ ) ; 

CldM. State  //  "Awaiting  MIT"  => 

MSGErrorC 'XMIT  received  ir.  w-or.g  state'); 

OldM. State  <-  "Awaiting  MES^-OK";* 

Ser.  d MESS  ( Old  M) ; 

END; 

Re lease (OldM) ; 

END; 

AnswerBelatedltem  <- 

EXPR(i  ^:MessBlock,  Command : Protocol  Code,  Reason : Reason  Code) 

BEGIN 

M <=  = AllocateCMessHar.dle,  M); 

M.  Protocol  Command  <-  Command; 

M. Reason  <-  Reason; 

DcliverToRe;noteHost(M, 

BEGIN 

Command  = "MESS-CANCEL"  => 

M.DestProce  S3 . Host; 

M. Source Process .Host ; 

END); 

Free(M) ; 

END; 

MessMismatch  <- 

t 

! OldM  is  an  existirg  transaction;  NewM  is  a new  protocol  item, 
j Return  TRUE  iff  NewM  refers  to  the  same  transaction  as  OldM. 

» */ 

EXPR(01dM:MessHar.dle,  NewM:MessBlock;  BOOL) 

OldM.  SourcelD  //  New!*:.  SourcelD  OR  OldM.DestID  //  NewM.DestID  OR 
OldM.SourceProcess  //  NewM.SourceProcess  OR 
OldM.DestID  //  NewM.DestID; 


'.00 
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DabitBuffer  <- 

I 

! Charge  the  space  for  M.Text  to  its  destination  D,  which  is  either 
! a specific  process  or  a generic  category. 

! If  D is  a specific  process  and  free  space  has  dropped  below  the 
! minimum  desirable  level,  cancel  held  Messes  until  enough  buffer 
! sp3ce  is  reclaimed. 

' */ 

EXPR  ( D : Dest  i land  le , M : Mess  Hand  1 e ) 

BEGIN 

D.FreeBuf ferSize  <-  D.FreeBufferSize  - M.TextLergth; 
IsProcescHar.dle(D)  -> 

FOREACH  CldM  IN  D. OutputMessQ 
DO 

D.FreeBufferSize  GE  Mir.MessHoldThreshold  => 

/*  ’No  need  to  cancel  further  held  Messes’; 

OldM. State  = "Awaiting  X4IT"  -> 

Car.celMess(01dM,  D); 

END; 

END; 

CreditBuffer  <- 

i 

! Credit  the  space  for  M Text  to  its  destination  D,  which  is  either 
! a specific  process  or  a generic  category. 

! If  free  space  now  permits  buffering  additional  Messes, 

! request  transmission  of  any  beirg  held  by  their  senders 

! until  VirtualFreeSpace  drops  below  a desirable  minimum. 

» 

' V 

EXPR  (D:  DestHar.dle , MiMessHar.dle) 

BEGIN 

D.FreeBufferSize  <-  D.FreeBufferSize  + M.TextLergth; 

FOREACH  OldM  IN  D. OutputMessQ 
DO 

Virtual Frc»eSpace(D)  LT  Request JMITThreshold  => 

/*  'No  room  to  request  further  transmissions'; 

OldM. State  = "Held  by  sender"  -> 

RequestTrar.smission(01dM,  D); 

END; 

END; 


•i  If  ir 
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VirtualFreeSp3ce 
EXPR(D: DestHar. die;  Integer) 

D.FreeBufferSize  - D.CommittedBufferSp3ce ; 

CommitBuffer  <- 

i 

! Try  to  hold  sane  of  Ds  buffer  space  for  a Mess  M kr.owr.  to  be  coming. 

' */ 

EXPR(D:DestHar.dle,  M:MessHar.dle) 

D.  Commit ted Buff or Space  <- 
D . Comm  itteJBu  f ferSpace  + M.TextLength; 

RemitBuffer  <- 

i 

! Inverse  of  CommitBuffer . 

i 

’ */ 

EXPR(D:I>3stHardle,  M:MessHar.dle) 

D.CommittedBuf ferSpace  <- 
D.CommittedBuf ferSpace  - M.TextLer.gth; 
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| Send  message-related  protocol  items  to  a remote  MSG  ir.star.c 

: v 

SendMESS  <- 
E XPR ( M : Mes  sHar  d le ) 

BEGIN 

M.  Pro  toco  lCommar.d  <-  "MESS"; 

Deliver To RemoteFbstCM,  M. DestProcess. Best) ; 

END; 

Se.'.dMESSXOK  <- 
E XPR  ( M : M sHar.d  le ) 

BEGIN 

M. Protocol Command  <-  "MESS-OX"; 

Deliver To Remotetbst(M,  M. SourceProcess.Host) ; 

END; 

Ser.dMESSXREJ  <- 

EXPR  (MrMessHardle , Reason : Reasor.Code) 

BEGIN 

M.  Pro  toco  lCommar.d  <-  "MESS-REJ"; 

M. Reason  <-  Reason; 

DeliverToRemoteHost(M,  M.SourceProcess .Host) ; 

END; 

SerdMESSXCANCEL  <- 

EXPR(M : Mess Handle , Reason : Reason  Code) 

BEGIN 

M.  Protocol  Command  <-  "MESS-CANCEL”; 

M. Reason  <-  Reason; 

Deliver To RemoteHost(M,  M. DestProcess. Host) ; 

END; 

Ser.dMESSNHOLD  <- 
EXPR(M:MessH3r.dle) 

BEGIN 

M.ProtocolCommar.d  <-  "MESS-HOLD"; 

Deliver ToRsmoteHost(M,  M. Source Process. Host) ; 

END; 
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Ser.dXMIT  <- 
EXPR ( M : Mess  Hard 1 e ) 

BEGIN 

M. Protocol  Comnar.d  <-  "X-1IT"; 
DelivcrToR.enote!bst(M,  M. SourceProcess.(bst) 
END; 
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Alarm  Handling 


*/ 


EnQOutputAlann  <- 

! A represents  an  ala.rn  sert  by  process  SP. 

! If  the  destination  process  is  local,  make  a record  for  the 
! input  and  call  Er.OIr.  put  Alarm  directly. 

i 

’ */ 

EXPR(A:AlarnHar.dle,  SP: ProcessHar.dle) 

BEGIN 

A. State  <-  "Awaitirg  ALARM-OX'*; 

Insert (SP. Output Alarms,  A); 

StartTimirg(A); 

A. Dest Process. Host  //  LocalHost  =>  Ser.dALARM(A) ; 

Ir.putA  <==  CopyAlarnHardle(A) ; 

EnQInputAlarmdrputA,  SP); 

Free(InputA); 

END; 

EnQReceiveAlann  <- 

» 

! RA  represents  a ReceiveAlarn  (called  "Enable  alarm"  in  the  MSG  Design 
! Specification)  primitive  issued  by  process  DP. 

! If  no  matching  ALARM  item  has  yet  arrived,  enqueue  RA  and  set  its 
l timer. 

! If  ALARMS  have  been  accepted,  take  the  first,  AR,  out  of  the  queue 
! and  merge  it  with  RA.  Compete  the  ReceiveAlarn  successfully. 

j 

» »/ 

EXPR(RA:AlarnHandle , DP: ProcessHandle) 

BEGIN 

Null(DP. InputAlarmQ)  => 

BEGIN 

EnQ(DP. ReceiveAlarmQ) ; 

RA. State  <-  "Awaiting  ALARM"; 

StartTimir.g(RA); 

END; 

AR  <==  Fror.t(DP.InputAlarnQ); 

Seize(AR); 

StopTimirg(AR) ; 

DeQ(DP. InputAlarmQ,  AR); 

MergeAlarmHandles(RA,  AR); 

Free(AR) ; 

Del ivor(RA,  DP); 

END; 
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Er.QIr.putAlarn  <- 

i 

! A represents  ar.  input  ALARM  item. 

! SP  represents  the  source  process,  if  local.  Otherwise,  it  is  null. 

! Reject  A if  its  destination  process,  DP,  cannot  be  found  or  if  it  is 
! not  accepting  alarms. 

! If  DP  has  issued  a ReceiveAlarm,  RA,  that  is  pending,  then  accept  A 
! and  merge  it  with  RA  to  complete  the  Receive. 

! Ir  th9re  is  r.o  pending  Receive,  but  DPs  input  alarm  queue  has  room, 

! accept  A and  queue  it. 

! Otherwise,  reject  A because  of  the  full  irput  queue. 

’ V 

EXPR  ( A : AlarmHar.dle,  SP:  Process  Handle) 

BEGIN 

DP  <==  Sei ze Process Hand le( A. Dest Process ) ; 

Null (DP)  => 

RejectAlarmC A,  "Destination  process  unknown",  SP); 

BEGIN 

NOT  DP. I Accept  => 

RejectAlarmC A,  "Process  not  acceptirg  alarms  now", 

3P); 

Null (DP. ReceiveAlarmQ)  => 

BEGIN 

IsFullQCDP. Ir.putAlarnQ)  r> 

RejectAlarmC  A,  ".Alarm  queue  for  process  is  full", 

SP); 

Accept AlarmC A,  SP); 

A. State  <-  "Awaitirg  ReceiveAlarm" ; 

EnQ(DP. Irput AlarmQ,  A); 

StartTimirgCA,  Aw3itirgReceiveIr.terval) ; 

END ; 

AcceptAlar.nC A,  SP); 

RA  <==  Fror.t(DP.  ReceiveAlarmQ) ; 

Seize(RA) ; 

StopTimir.g(RA) ; 

DeQCDP. ReceiveAlarmQ,  RA); 

MergeAlarmHar.dlesCRA,  A); 

Deliver(RA,  DP); 

END; 

Release(DP); 

END; 
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MergeAlarmHar.dles  <- 

t 

! RA  represents  a ReceiveAlar;n  primitive  into  Wiich  the  information 
! in  A,  an  input  alarm,  must  be  merged,  so  that  RA  can  be  delivered. 

i 

• */ 

EXPR(RA:Alar:nHar.dle,  A:AlarinHandle) 

BEGIN 

RA. Alarm  <-  A. Alarm; 

RA. Source Process  <-  A.  Source  Process ; 

RA. Disposition  <-  "Normal"; 

END; 

Record ALA RM\0K  <- 

t 

! AOK  represents  an  ALARM -OK  item. 

! Find  and  complete  the  corresponding  Send  Alarm  event. 

i 

' */ 

EXPR(AOK:Alar.nBlock) 

BEGIN 

A <==  SeizeTrar.sactior.C  AOK.  SourcelD) ; 

Null(A)  OR  NOT  IsAlarmHar.dle(A)  OR 
A. Dest Process  //  AOK. DestProcess  => 

/*  'Send Alarm  may  have  timed  out'; 

SP  <==  SeizeProcessHar.dlcC  A.SourceProcess) ; 

Remove(SP. Output AlarmS,  A); 

A. Disposition  <-  "Normal" ; 

Deliver( A,  SP); 

Release(SP) ; 

REL(A); 

END; 

RecordALARMXREJ  <- 

» 

! AR  represents  an  ALARM-RE J item. 

! Find  and  abort  the  corresponding  Send Alarm  event. 

! 

• */ 

EXPR(AR:AlarmBlock) 

BEGIN 

A <==  SeizeTrar.sactior.C  AR.  SourcelD) ; 

Null (A)  OR  NOT  IsAlarnHardle(A)  OR 
A. DestProcess  //  AR. DestProcess  => 

/*  'Send Alarm  may  have  timed  out1; 

SP  <==  SeizeProcessHar.dleCA.  Source  Process) ; 
Remove(SP.OutputAlannS,  A); 

A. Disposition  <-  AR. Reason; 

DeliverCA,  SP); 

Release(SP) ; 

Release(A); 

END; 
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Accept Alarm  <- 

» 

! A represents  an  input  Alarm  to  be  accepted. 

! SP  is  the  source  process,  if  local;  otherwise  it  is  null. 

! If  the  serder  is  remote,  send  an  ALARM -OK. 

! If  local,  find  and  complete  the  original  Send Alarm  event. 

! It  is  unnecessary  to  seize  Source A:  the  callirg  path 
! has  it  already. 

i 

' */ 

EXPR(A:AlannHar.dle,  SP: ProcessHandle) 

BEGIN 

Null(SP)  =>  Ser.dAL\RM\CK(A); 

SourceA  < = = LookupTrar.sactiorCA.  SourcelD) ; 
DeQCSP.OutputAlarmS,  SourceA); 

SourceA. Disposition  <-  "Normal"; 

Deliver(SourceA,  SP); 

END; 

RejectAlarm  <- 

t 

! A represents  an  input  Alarm  to  be  rejected  for  the  Feasor,  given. 
! SP  is  the  source  process,  if  local;  otherwise  it  is  r.ul.., 

! If  the  sender  is  remote,  send  an  ALARM-REJ. 

! If  local,  find  and  abort  the  original  Ser.dAlarm  event. 

! It  is  unnecessary  to  seize  SourceA:  the  callirg  path 
! has  it  already. 

i 

• V 

EXPR(A:AlarnHar.dle,  SP:  ProcessHandle) 

begin 

Null(SP)  =>  Ser.dALARMXREJCA,  Reason); 

SourceA  <==  LookupTransactior.C A. SourcelD) ; 
DeQCSP.OutputAlarmS,  SourceA); 

SourceA. Disposition  <-  Reason; 

DeliverCSourceA,  SP); 

END; 
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i Tran  suit  alarm-related  protocol  items  to  a remote  MSG 

J 

’ V S 


Ser.d ALARM  <- 

E XPR  ( A : A1  ar.nHar.d  le ) 

BEGIN 

A.  ProtocolGonmar.d  <-  "ALARM”; 

Del iver To RenoteBostC A,  A. Dest Process . Host ) , 

END; 


Ser.d  ALA  RM\0K  <- 

E XPR  (A:  A1  ar.nHar.d  le) 


BEGIN 

A.  ProtocolGonmar.d  <- 
Del  iver  To  Remote  Bos  t(  A , 

END; 


ALARM-OX”; 

A. Dest Process.  Bost) ; 


Ser.dALARMNREJ  <- 

EXPR(A:Alar:nHardle,  Reason : Reason  Code) 

BEGIN 

A.  Protocol  Co  uni  and  <-  ”ALARM-REJ”; 

A. Reason  <-  Reason;  .. 

DeliverToRenoteHostC A,  A.DestProcess.Bost) 


END; 
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! 

! Har.dle  Direct  Cor.r.ectiors 

j 

! 

Eh  QOutpu  toper.  Corn  <- 

t 

! Process  SP  has  issued  ar.  Open  Corn , represented  by  OjtC. 

! OutC.Corr.Bytesize  and  OutC.Corr.Type  have  beer,  validated, 
j Scar,  its  correction  set  for  ore  with  the  sane  Cor r. ID  as  OjtC, 

! and  reject  OjtC  if  another  ore  exists. 

! If  r.o  request  for  a correction  with  name  OjtC.Corr.ID  has  yet  beer,  received, 
! then  transmit  a CONN-OPEN  to  the  remote  process  (or  simulate  sane  if 
! that  process  is  local),  ard  put  OutC  ir.  the  set  of  outgoing  correction 
! requests  for  SP. 

! If  there  is  a correspond irg  incoming  request,  call  it  Ir.C.  If  the  remote 
! process  names  of  Ir.C  and  OutC  do  not  match,  then  reject  OutC. 

! Check  that  Ir.C  and  CXitC  have  agreeable  types  ard  byte  sizes.  If  not, 

! abort  the  local  per.dirg  open,  which  will  cause  COM-CLOSE  to  be  sent 
! to  the  remote  process. 

! If  the  correction  types  agree,  complete  the  Open  Con  r.  primitive 
! successfully,  merge  the  input  Corn  Har.dle  into  CutC,  discard  Ir.C,  ar.d 
! enter  the  merged  Corr.Har.dle  ir  SPs  set  of  open  cor.r.ectiors. 

t 

• V 

EXPR ( Qj  t C : Conn  Hand 1 e , S P : Process  Hand 1 e ) 

BEGIN 

Ir.C  ==  Conn  Har.dle; 

FOREACH  C IN  SP. Connections 
DO  C.  Corn  ID  r Ir.C.  Corn  ID  =>  Ir.C  <-  C END; 

NOT  (Null(Ir.C)  OR  InC. State  = ’’Awaiting  Oper.Cor.n”)  => 

BEGIN 

OutC. Disposition  <- 

’’Already  have  connection  of  that  ID”; 

Deliver(OutC,  SP); 

END; 

Null  (Ir.C)  => 

BEGIN 

Ir.sert(SP. Connections,  OutC) ; 

OutC. State  <-  ’’Awaiting  CONN-OPEN”; 

S3r.d0per.Cor.r(0utC,  SP); 

END; 

A a 
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QjtC.  Dost  Process  if  Ir.C.  Source  Process  => 

BEGIN 

OutC. Disposition  <- 

"Correction  not  to  process  named"; 

Deliver (OutC,  3P); 

END; 

StopTimir  2 (Ir.C) ; 

Remove (SP. Connections,  Ir.C); 

BEGIN 

CompatibleCor.rTypes( Ir.C,  (XitC,  OjtC. Disposition)  => 
BEGIN 

Mer  ge  Conn  Hand  les(CXjtC,  Ir.C); 

InsertCSP. Corrections,  Sot C) ; 

OutC. State  <-  "Connection  open"; 

OjtC. Disposition  <-  "Normal"; 

Send  Open  Cor  r.  ( Oj  tC , 3P); 

END; 

DP  ==  ProcessHar.dle ; 

OutC.  Dost Process. Host  = LocalHost  -> 

DP  <-  SeizeProcessHar.dleOjtC.  Dost  Process ) ; 
RejectGorr.OutC,  OjtC. Disposition , DP); 

Release ( DP ) ; 

END; 

DeliverOotC,  SP); 

Free(Ir.C); 

END; 

MergeCor.r  Handles  <- 

t 

! OutC  and  Ir.C  are  matchirg  connection  open  requests.  OutC  will 
! become  the  permanent  record  of  the  connection,  so  merge  info 
! from  Ir.C  into  it. 

1 

; */ 

EXPR  ( CucC : Corn  flar.dle , Ir.C : Corn  Handle ) 

BEGIf 

OutC.DestID  <-  Ir.C.  Source  ID; 

OutC.RemoteSocket  <-  Ir.C.Ra.noteSocket; 

END; 
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EnQIrputOper.Corr  <- 

! ir.C  represents  ar.  incoming  request  to  open  a connection. 

, SP  is  ror.-r.ull  if  the  request  is  from  a local  process,  lr.  which  .ase 
i it  is  the  handle  for  that  process. 

! Assume  that  Ir.C.Gorr.Bytesize  and  Ir.C.  Cor  r.Type  are  le^1- 
! Look  for  destination  process.  If  found,  call  it  DP.  If  not, 

! reject  the  connection  request. 

! Look  for  a pending  ('per.Conn  by  DP  with  same  correction  ID 

as  irC  If  ror.e  found,  then  eitner  reject  Ir.C  (if  it  mentions 
a particular  transaction),  or  enqueue  it  to  await  t£e  local  open. 

If  a pending  output  request  is  found  cal^itajtC.^cktha 
th^  re-note  process  is  the  same  for  Ir.C  fo.  OutC  i tnzi  * 

. agr'ee  on  the  local  transaction  ID  if  IrC  claims  to  know  it. 

! Havirg  establishei  that  Ir.C  and  OutC  refer  to  the  sam-  c^nr.^tior., 
i ch’Ck  that  a COXI-OPEN  is  acceptable  m its  current  state.  If 
I r.ot  reject  the  open.  If  state  is  "Awaiting  CONN-OPEN  or 
! CONN-CLOSE",  then  adjust  the  state  but  otherwise  lgror. 

! Scop  timirg  or.  OutC  ar.d  remove  it  from  D.  .uorrectiorS.  ... 

Check  the  compatibility  of  Ir.C  ar.d  OutC  If  they  are 

: srs * *. 

i remote  process.  Ir.  either  case,  enter  OutC  ir.  DP.-otnectionS  and 
• discard  Ir.C.  If  the  connection  has  beer,  abor-ed,  CUtC  oits  ir. 
i DP?Cor r.ectior.S  until  ar.  answering  CLOSE-CONN  is  received  or  a 
! time-out  occurs. 


! 


*/ 

EXPiU  Ir.C:  Cor.r.Har.dle , SP:ProcessHar.dle) 

BEGIN  ^ , 

DP  <==  Seize  ProcessHar.dle(  Ir.C.  DestProcess) , 

Null  (DP)  =>  . rpi. 

RejectCor.r.CIr.C,  "Destiration  process  unknown  , oH, 

OutC  ==  Cor.r.Har.dle; 

BEGIN 

FOREACH  C IN  DP. Connections 

DO  C.  Conn  ID  = Ir.C.  Conn  ID  =>  OutC  <-  C END, 

Null(OutC)  => 

BEGIN 

NOT  Null(Ir.C.DestlD)  => 

RejeetOor.r.(InC^rerced  corKeetion  tran9actior.  does  not  exist", 
SP)  * 

terdir.ality(DP. Corrections)  GE  Max  Corrections  => 

Re^  "Destination  process  connection  limit  reached  , 

SP); 

InC. State  <-  "Awaiting  OpenCor.r"; 

StartTimir.gdr.C,  AwaitingOper.  Conn  Interval) ; 

Insert (DP. Connections,  InC) ; 

END; 


Abstract  Model  of  MSG 
Module  QUEUE 


1 


OutC.testProcess  It  Ir.C.SourcaProcess  OR 
NOT  Null(Ir.C.DestlD)  AND  OutC.SDurcelD  It  Ir.C.DestID  :> 
RejoctOjr.rdr.C, 

'Correction  ID  ir.corsister.t  with  local  correction  info” 
SP)  ; 

CXjtC.  State  = "Awaiting  CON'J -OPEN  or  CONN -CLOSE”  => 

CXitC. State  <-  "Awaiting  CONN-CLOSE”; 

OjtC. State  //  ’’Awaitirg  CONN-OPEN"  => 

RejectCorr( IrC,  "Already  have  correction  of  that  ID”, 

StopTimirg(OutC) ; 

MergeCorr.Har.dlesCCutC,  Ir.c); 

C°'n?-T»bleCorrTyp33(IrC'  011  tc.  CUtC. Disposition)  => 

BEG  iif 

OutC. State  <-  ’’Cor.r.ectior  open”; 

CXitC.  Disposition  <-  "Normal";  * 

Deliver(OutC,  SP); 

END; 

CXitC.  Soate  <-  "Mismatch  - awaiting  CONN-CLOSE’’* 

Send  Close  Conn  ( CXitC , OutC.  Disposition,  DP): 

END;  * 

Release(DP) ; 

END; 

CompatibleCorrectior.Types  <- 

* 

! Returr.s  TRUE  iff  Cl  and  C2  have  the  same  byte  size  and  complementary 
! connection  types. 

j Sets  disposition  appropriately  if  there  is  a misnatch. 

* V 

EXPR (Cl: Conn Hand le , 

C2: Conn Handle , 

Disposition : Reason Code  SHARED: 

BOOL) 

BEGIN 

CI.CorrBytesize  //  C2. GonnBytesize  => 

BEGIN 

Disposition  <-  "Connection  byte  size  mismatch"; 

FALSE; 

END; 

CASE[C  1 . Corr.Type , C2. Cor.nType] 

["ServerTELNET" , "User TELNET"] , 

["User TELNET" , "ServerTELNET"]  r>  TRUE* 

["Binary",  "Binary"]  => 

CAS£[C  1.  Conn  Direction , C2.Cor.nDirection] 

["I^Out",  "InOut"],  ["In",  "Out"],  ["Out",  "In"]  => 

TRUE  =>  FALSE; 

END; 

TRUE  =>  FALSE; 

END  =>  TRUE; 

Disposition  <-  "Connection  type  mismatch"; 

FALSE; 

END; 
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tyenCorn  <- 

1 If  CXitC  is  addressed  to  a local  process,  ther.  simulate 
! transmission  of  a COM-OPEN  by  copying  OutC  ar.d  calling 
! tie  handler  for  input  CONN-OPSNs. 

! Otherwise,  send  a CONN -OPEN  to  the  remote  process. 

' */ 

EXPiUOutC: Cor.r.Handle , SP:  ProcessHardle) 

BEGIN 

COtC.  Dest Process .Host  = LocalBost  => 

BEGIN 

Ir.C  <==  ReverseCor.r.Hardle(OutC) ; 

En  QIn  put  Open  Con r.(  Ir.C,  3P); 

Free(Ir.C); 

END; 

OutC. Protocol Comm and  <-  "CONN-OPEN"; 

Deliver To Remote Bos t( JutC,  OutC. Dest Process. Host) ; 

END; 

Send Close Conn  <« 

i 

! If  CXitC  is  addressed  to  a local  process,  then  simulate 
• transmission  of  a CONN-CLOSE  by  copying  OutC  and  calling 
! the  handler  for  input  CONN-CLOSEs. 

! Otherwise,  send  a CONN-CLOSE  to  the  remote  process. 

' V 

EXPR  (CXitC:  Conn  Handle , Reason : Reason  Code . SP:  ProcessHar.dle) 
BEGIN 

CXitC.  Reason  <-  Reason; 

CXitC.  Dest  Process.  Host  = LocalHost  => 

BEGIN 

InC  <==  ReverseConr.Handle(OutC) ; 

InC. Reason  <-  OutC. Reason; 

EnQInputCloseCor.r.UnC,  SP); 

Free  ( Ir.C ) ; 

END; 

CXitC . Protocol  Command  <-  "CONN-CLOSE"; 

DeliverToRimoteHostCOutC,  OutC. DestProcess. Host) : 

END; 
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ReverseCorr Handle  <- 

» 

! Produce  a copy  of  C with  Source  and  Destination  reversed,  so  that 
! a reply  to  C car.  be  ser.t. 

i 

’ V 

E XP  R ( C : Corn  Hard le ; Corn Handle) 

BEGIN 

InC  <=r  CopyGonr.Hardle(OutC) ; 

Ir.C.  Source  ID  <-  CtitC.DestID; 

InC. Source Process  <-  OutC.  Dost  Process; 

InC.DestID  <-  OutC. Source ID; 

InC. Dest Process  <-  OutC.SourceProcess ; 

InC; 

END; 
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EnQOutputCloseCorr.  <- 
« 

NewC  represents  either  a CLoseCor.r.  primitive  or  ar.  Oper.Corn  for  which 
an  error  has  occurred  tryirg  to  establish  the  connection. 

Either  way,  it  is  known  that  ar.  0 per. Corn  has  been  performed  with  ld.rtif ler 
NewC. Conn  ID.  Call  the  original  Corn Handle  OldC  (which  will  be  identical 
to  NewC  if  this  call  results  from  an  error).  . . _ 

Ch^k  that  the  destination  process  is  cor.sistert  with  the  original  ope 
Substitute  NewC  for  OldC  ir  th:.  Trar.sactior.Table  entry 
corresponding  to  this  transaction.  A single  transaction  ID  will 
be  used  for  both  primitives. 

Take  action  depending  on  OldC. State. 


*/ 


EXPR  (NewC  :Cor.r.  Handle , SP:  ProcessHar.dle) 


BEGIN 
OldC  <== 

BEGIN 

NewC. Op  if  "CloseCorr.ectior."  =>  NewC; 

Sei zeTr ansae  t ion ( NewC . Sour ce ID ) ; 

END; 

FOREACH  C IN  SP. Connections 
DO 

NewC.  Conn  ID  = C.  Com  ID  => 

[)  OldC  <-  C;  OldC  if  NewC  ->  Seize(OldC)  (]; 

END; 

BEGIN 

OldC. Dest Process  if  NewC. Dest Process  => 

BEGIN 

NewC. Disposition  <- 

"Connection  r.ot  to  process  named”; 

Deliver (NewC,  SP); 

END;  _ 

Replace  Tr  ar.saction  Handle  (OldC.  Sour  celD,  Newo); 

CASEtOldC. State] 

["Awaiting  CONN-OPEN"]  => 

t 

i User  process  issued  Close  before  completion 
i of  Open.  Abort  the  Open Conn,  send  CONN-CLOSE, 

! wait  for  possible  CONN-OPEN,  then  CONN-CLOSE, 

! and  abort  the  CloseCorn  after  this  exchange. 

i 

' */ 

BEGIN 

StopTimir.g(OldC) ; 

OldC. Disposition  <-  "Superseded  by  close"; 
Remove(SP. Connections,  OldC) ; 

Deliver (OldC,  SP); 

Release(OldC) ; 

NewC. State  <- 

"Awaiting  CONN -OPEN  or  CONN -CLOSE"; 

NewC. Disposition  <-  "Connection  not  yet  open"; 
Insert (SP. Connections,  NewC) ; 

Star  tT  im  i r.  g ( NewC ) ; 
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Send  CloseCor.r  (NewC,  "Oper.  superseded  by  close", 

SP); 

END; 

["Correction  oper."]  => 

» 

! Gould  be  a normal  Close  or  error  durirg  cor.r.ectior.  attempt. 
! Replace  OldC  by  NewC  ir  the  cor.r.ectior  set.  (Do  this  before 
! freeirg  OldC,  ir  case  OldC  = NewC!). 

! Ser.d  CONN-CLOSE  ar.d  wait  for  ackr.owledgenert. 

! NewC. Disposition  irdicates  error,  if  ary. 

• */ 

BEGIN 

Renove(SP. Corrections,  OldC); 

MergeOper. Ir toClose( NewC , OldC) ; 

Insert (SP. Corrections,  NewC) ; 

Free(OldC) ; 

NewC. State  <-  "Awaiting  CONN-CLOSE"; 

Star tTimirg( NewC,  Awaitir.gCONNXCLOSEIrterval) ; 

Send Close  Corn (NewC,  NewC. Disposition , SP); 

END; 

["Mismatch  - awaiting  CONN-CLOSE"]  => 

! An  Oper  Com  is  pending.  Abort  it  immediately . 

! CONN-CLOSE  has  already  beer,  sent.  Await  the  reply, 

! then  abort  the  CloseCor.r. 

» 

* */ 

BEGIN 

StopTimir.g(OldC) ; 

Removed P. Corrections,  OldC); 

MergeOper  Ir.toClose(  NewC,  OldC) ; 

Deliver(01dC,  SP); 

NewC. St3te  <-  "Awaitirg  CONN-CLOSE"; 

NewC. Disposition  <-  "Correction  rot  yet  oper"; 

Ir sert (3 P. Corrections,  NewC); 

StartTimir.g(NewC) ; 

END; 

["Awaiting  CloseCor.r."]  => 

« 

! Could  be  normal  Close  or  error  durirg  attempt  to  correct. 

! NewC. Disposition  indicates  which. 

! (Freeirg  of  OldC  must  follow  delivery  of  NewC  ir  case  the 
! two  are  identical!) 

! 

1 V 
BEGIN 

StopTimir.g(OldC) ; 

Remove(SP. Corrections,  OldC); 

Deliver (NewC,  SP); 

Free(OldC) ; 

END; 

["Awaiting  CONN-CLOSE"], 

["Awaiting  CONN^CPEN  or  CONN-CLOSE"]  => 

BEGIN 


•.-i’-iifcl 
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NewC. Disposition  <-  "Redundant  close”; 

DeliverCNewC,  3P); 

ENl,; 

END; 

END; 

OldC  I!  NewC  ->  Release(OldC) ; 

END; 

MergeOpenlrtoClose  <- 

t 

! CloseC  is  about  to  replace  Oper.C  ir.  a set  of  Corrections. 

! Copy  the  necessary  connection  ir  form  a tier,  from  OpenC  to  CloseC. 

i 

: V 

EXPR ( CloseC : Conn  Hand 1 e , Open  C : Conn  Hand  1 e ) 

BEGIN 

CloseC. Dest ID  <-  OpenC. Dost ID; 

CloseC. Connection  <-  OpenC. Com ectior  ; 

CloseC. Local  Socket  <-  Oper C. Local Socket ; 

CloseC. RemoteSocket  <-  Open C. RemoteSocket ; 

END; 


Reject  Conn  <- 

i 

! IrC  is  ar  incoming  Conn  Open  or  Cor.r.Close  request,  which  must 
! be  rejected. 

! SP  is  the  source  process,  if  local,  otherwise  null.  In  the  local  case, 
! it  is  not  necessary  to  seize  the  source  transaction  because 
! the  calling  path  already  has  it. 

! 

1 V 

EXPR (InC: Conn Handle,  Reason:  Reason  Code,  SP:  ProcessHar.dle) 

BEGIN 

Null(SP)  =>  SerdCQNN\REJ(ReverseCorrHar.dle(Ir.c) , Reason); 
RejectOitputCor.r.(LookupTransaction(InC.SourceID) , Reason, 

SP); 

END; 

RejectQjtputCor.r  <- 

t 

! (XitC  is  an  output  Open  Conn  or  CloseCor.n  from  process  SP. 

: It  is  to  be  rejected  for  the  Reason  given. 

! Be  sure  QjtC  is  in  the  proper  st3te  to  receive  a rejection. 

! If  so,  abort  QjtC,  passing  along  the  reason  for  rejection  unless 
! OutC  holds  a prior  error  code,  which  takes  precedence. 

’ V 

EXPR  (OutC : Cor.nHandle , Reason  :ReasonCode,  SP:  ProcessHandle) 

BEGIN 

OldC. State  = ’’Connection  open”  OR 
OldC. State  = "Awaiting  Open Conn”  OR 
OldC. State  = ’’Awaiting  CloseConn”  => 

MSGError( 'Connection  rejection  in  wrong  state'); 

StopTiming(OldC) ; 
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IsNorinaKOldC. Disposition)  ->  OldC. Disposition  <-  Reason • 
Retnove(SP.  Connections,  OldC); 

Deliver(01dC,  SP); 

END; 


\ 
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EnQIr.putCloseCor.r  <- 

i 

! NewC  re  presorts  an  incoming  correction  close  request. 

! If  SP  is  non-null,  then  the  correction  is  intrahost,  and  SP  represents 
! the  source  of  this  Close. 

! Look  for  a correction  record  that  either  represents  a previous  input 
•'  CONN -OPEN  (State  r "Awaiting  Open Corn"),  or  the  local  response  to  such 
! an  input. 

! If  r.o  destination  or  no  matching  connection  car  be  found,  reject  the 
! Close  unless  tne  reason  accompanying  it  is  "ACKir.g  your  close".  Such 
! a belated  Close  could  result  from  timeouts. 

! Otherwise,  take  action  appropriate  to  the  state  of  the  connection  found. 
' */ 

EXPR  (NewC  :Cor.r.  Handle,  SP: ProcessHar.dle) 

BEGIN 

DP  <=  = SeizeProcessHandle(NewC. Dest Process ) ; 

Null (DP)  => 

NewC. Reason  //  "ACKir.g  your  close"  -> 

Reject Corn (NewC,  "Destination  process  unknown.",  SP); 

BEGIN 

CldC  ==  Conn Har die ; 

FOREACH  C IN  DP.Conr.ectiorS 
DO 

Matchir.gConr(C,  NewC)  => 

0 OldC  <-  C;  Seize(OldC)  (]; 

END; 

Null (OldC)  => 

NewC. Reason  //  "ACKir.g  your  close"  -> 

Rej ect Cor. r.( NewC , "Ifc  known  connection”,  SP); 

CASE[01dC. State] 

["Awaiting  Open Conn"]  => 

t 

! Sender  is  withdrawing  a previous  CONN-OPEN. 

! Acknowledge  and  discard  transaction. 

! 

* */ 

BEGIN 

StopTimir.g(OldC); 

Remove ( DP. Connections,  OldC); 
SendClcseCorr(ReverseCor.rHandle(01dC) , 

"ACKir.g  your  close",  DP); 

END; 

["Connection  open"]  => 

i 

! Sender  is  initiating  a connection  close  exchange. 

! Wait  for  local  process  to  respond. 

• «/ 

BEGIN 

OldC. State  <-  "Awaiting  CloseConn"; 

StartTimir.g(01dC,  Awaitir.gCloseConn Interval) ; 

END; 

["Awaiting  CloseConn" ] => 
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["Awaiting  CONN-OPEN"]  => 

MSGErrcrCLnproper  rcspor.se  to  CONN-OPEN'); 
["Awaiting  CONN-CLOSE"  ] , 

["Misnatch  - awaiting  CONN-CLOSE"], 
["Awaiting  CONN-OPEN  or  CONN-CLOSE"]  => 

BEGIN  J 

StopTirnir.g(OldC) ; 

Remove (DP. Corrections,  OldC ) ; 

I>eliver(01dC,  DP): 

END; 

END; 

Release(OldC) ; 

END; 

Release(DP) ; 

END; 

Matching Corn  <- 

EXPR (OldC : Conr.Har.dle , NewC:  Gor.nHur.dle ; BOOL) 

BEGIN 

OldC. State  = "Awaitirg  Oper.Cor.r."  => 

OldC.  Saurce Process  - NewC.  Source  Process  AND 
OldC.SourcelD  = NewC. Source  ID; 

OldC . Dost  Process  = NewC.  Saurce Process  AND 
OldC.  EVestID  = NewC.SeurcelD  ANT) 

(Null(^wC.DestID)  OR  OldC.  Source ID  = NewC.DestID) ; 

L«11  U * 


RecordCONNXREJ  <- 

I 


i 

! 

i 

i 


CR  is  an  ir.ccmi r.g  CONN-REJ  item. 

If  the  designated  transaction  carr.ot  be  found,  igrore  CR. 
Otherwise,  abort  and  deliver  the  original  Open  Corn  or  CloseCor.n 


V 

EXPR (CR : Conn Block) 

BEGIN 

OldC  <=  = SeizeTrar.sactior(CR.DestlD); 

BEGIN 

Null (OldC)  OR  NOT  IsCorrHandle(OldC)  OR 
OldC. Source Process  # CR.Dest Process  OR 
OldC. Dest Process  //  CR .Scarce Process  => 

/*  'Transaction  could  have  timed  out'; 

SP  <==  SeizeProcessHar die (OldC. Source Process) ; 
Re jectOitput Corn  (OldC,  CR.  Reason , SP); 
Release(SP); 

END; 

Release(OldC) ; 

END; 


» 
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» 


Utility  Routir.es 


v 


Deliver  To  RemoteBost  <- 

» 

! T represents  a transaction  for  which  a protocol  item  must  be  sent 
! out  to  host  H. 

! 

’ */ 

EXPR(T :Trarsac tior Handle,  H: Host Code) 

BEGIN 

RH  <==  SeizeHostHandleCT. Dest Process. Host) ; 

Deliver(T,  RH); 

Released RH ) ; 

END; 

Deliver  <- 
» 

! U is  either  a local  process  or  a remote  host. 

! T is  a trarsactior.  with  output  ready  for  U. 

! Let  SH  be  the  delivery  server  for  U. 

! If  T is  an  alarm,  give  it  special  priority. 

! If  SH  is  asleep,  SIGNAL  to  wake  it  up,  and  set  a flag  to  avoid 
! redir.dar.t  SIGNALS  by  other  paths. 

• V 

EXPR(T : Transact  ion  Handle,  U:  UserHar.dle) 

BEGIN 

DECL  SH: Server Handle  LIKE  Seize(U. Delivery Server ) ; 

Non AlannsQj  cued  <==  FALSE; 

FOREACH  QT  AT  QTLocatior  From  Front Of  SH.DeliveryQ 
DO 

NOT  IsAlarrnHandle(QT)  => 

BEGIN 

Non  Alarms  Queued  <-  TRUE; 

Er. QA t ( QTLoc a t ion , T); 

END; 

END; 

NOT  Non  Alarms  Queued  ->  Er.QCSH.  Deli  very  Q,  T); 

Is ProcessH and le ( U ) ->  T. State  <-  "Delivered"; 

NOT  SH. Running  -> 

0 SIGNAL(SH.WakeUpSigral);  SH. Running  <-  TRUE  (]; 
Release(SH); 

END; 
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Matchir-sProcessNames  <-  conpatible 

i S*- 


\ 

« */ 


EXPR (GN ana : Proc asstbnva , Jtoa : Process, la-n- , B°° 

GNana-Host  * ! Vane.  Incarnation  AND 

SE’JS ^^--a,,StcS.rAN  s Narae.Instarca); 

(NaUCGN3-ne.Ir.st3r.Cw; 

Br.codeGer.en:Nwe  < 3 er.srlc  codes. 

i * >>ua 

®S  IdStricdglCldds)  ■> 

DO 


• */ 


end; 

Four.d  ; 
END; 


Aan  an  — 

' eFS^,?  <-STRUEf  c llss1  < -S3H . 0 


Code  O; 


Kfde«.ricadd.  <-  corresoor.dirg  «rl«. 

i Translate  a generic  class 

I ./  k . jPtr  Ger.ericClassOode)  SHARED) 

EXPR  ( Class : Uraor.  ( o^r  lr  g . 

BEGIN  „>  /*  'Already  decoded  , 

Class^<-^GenarlcTable[Class] .Class ; 
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! Transaction  Table  Access 

! Transaetior.Table  maps  Transaction  IDs  irto  Trar.saetionHardles. 
i Ot\Q  passible  method  of  encoding  table  indices  as  part  of  transaction 
! identifiers  is  described  in  the  MSG  Desigr  Specification. 

! Transaetior.Table  entries  are  allocated  by  Assi3nTrans3ctior.II)  and 
! freed  by  Free. 

! 

' »/ 

LookupTransactior.  <-  , 

EXPR(  ID:  Transact  ion  ID;  Transaction  Handle)  Transactior.TableLID  J ; 

SeizeTrar.s  action  <- 

EXPR(  ID:  Transaction  ID;  Trar.sactionHar.dle) 

Seize(LookupTransactior.(ID)) ; 

ReplaceTrar.saetionHar.dle  <- 

EXPR( ID: Transaction  ID,  TH:TransactionHandle) 

LookupTransactior (ID)  <—  TH ; 

« _ _ _ 

1 

! Process  Table  Access 

! ProcessTable  maps  local  process  instance  identifiers  to  ProcessHandles 
! A method  of  encoding  table  indices  in  instance  numbers  which  results  ir. 
S infrequent  reuse  of  irstar.ee  identifiers  is  described  ir  the  MSG  Design 

! Specification. 

! 

’ »/  -5 

LookupProcessHar.dle  <- 

EXPR(P: Process Name ; Process Handle)  ProcessTable[P. Instance] ; 

Seize ProcessHar.dle  <- 

EXPRlP:  Process  Name;  ProcessHar.dle) 

Seize(LookupProcessHandie(P)) ; 


jttHBUadlhiiaaWMkJi 
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!- 

! 

i Cancell irg  Transactions 

i 

! — 

! There  are  four  ways  a transaction  event  may  terminate  abnormally: 

! . Rescind 

! . St  op  Me 

! . host  death 

! . timeout 

! These  possibilities  are  considered  in  the  table  which  follows.  It  cortairs 
•all  possible  transaction  states  and  the  action  to  be  taker,  for  each  state. 

! Table  entries  have  the  form: 

! state  name 

! conditions  precedert  to  this  state 

! remote  action  taken  isr.  or. ter ir 3 this  state 

! local  actior  taker,  when  cancelling 

! remote  action  taker,  wier.  cancelling 

I (parenthetical  remarks  irdicate  later  ir.deper.der  t resporses) 

! possibility  of  Rescind 

IT  and  P are  the  transaction  at  issue  and  its  owr.ir  3 process.  The  S ard  u 
*! prefixes  indicate  source  ard  destination  respectively.  R is  the  delivery 
! queue  of  the  network  server.  Tir.R  is  true  when  T is  in  R.'; 

• Mess  Output 

I 

! Awaiting  MESS-0 K 

| OutputMess  1 Awaiting  XMIT  4 XMIT  received 

l send  MESS 

! [)  Stop  Me  =>  DcQ  ( S P . Ou  t ?u  t Mess  Q , ST);  RejectCUtputMessUP)  U 

! Tir.R  ->  [)  Old  =>  set  MESS-CANCEL;  DoQ(R,  ST)  (] 

i (Not  Tir.R:  MESS-HOLD  received  — send  MESS-CANCEL) 

! Tir.R  ->  rescissible 

! Awaiting  XdIT  (remote) 

! Awaiting  MESS-0 K 4 MESS-HOLD  received 

! send  HOLD-OfC 

! [)  StopMe  =>  DeQCSP. OutputMessQ,  ST);  Reject0utputM35s(SP)  (J 

! [)  Tir.R  =>  set;  send  (]  MESS-CANCEL 

! rescissible 

! Awaiting  XdIT  (local) 

I OutputMess 

! [)  StopMe  =>  DeQ(SP. OutputMessQ,  ST);  RejectOutputMess(SP)  (]; 

DeQ(DP. InputMessQ,  DT) 

! 

! rescissible 

! Awaiting  prior  MESS  completion 
! OutputMess  & (sequence  ! stream-mark)  block 

! [)  StopMe  =>  DeQ(SP. OutputMessQ,  ST);  RejectOjtputMess(SP)  (] 

! 

! rescissible*; 
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' Mess  Input 

i 

! Awaiting  HOLD-OX 

! MESS  received  & ro  buffer  space 

! send  MESS-HOLD 

! DeQ(DP.  Ir. putMessQ,  DT) 

! TirR  ->  set  MESS-REJ 

! (Not  Tir.R:  HOLD -OK  received  — send  MESS-REJ) 

i 

! Held  by  sender  (remote) 

! Awaitirg  HOLD-OX  V HCLD-OX  received 

i 

• CVaQC DP . Ir putMessQ,  DT) 

! send  MESS-REJ 

j 

! Held  by  sender  (local) 

! local  mess  received  £ r.o  dest  buffer  space  £ source  buffer  space 

! RejectOutputMess(SP);  DaQ(DP.  Ir.putMessQ,  DT) 


! Awaiting  retrar.snissior. 

! Held  by  re  note  sender  i buffer  space 

! send  WIT 

! DeQ(DP.  Ir.putMessQ,  DT);  Ren it Buffer (DP,  DT) 

! TinR  ->  set  MESS-REJ 

! 

! Awaiting  ReceiveMess 

local  mess  received  ! Held  by  local  sender  i buffer  space 
! ! MESS  received  & buffer  space 

! remote  ->  send  MESS-OX 

! DeQ(DP.  In  putMessQ,  DT);  CreditBuffer (DP,  DT) 


* Receive  Mess 

! 

! Awaiting  MESS 
! ReceiveMess 

j DeO([)  IsGer.eric(DT)  =>  DPsGeneric Handle;  DP  ( ]. ReceiveMessQ,  DT) 

! rescissible’ ; 
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1 Alarm  Output 

! 

! Awaiting  ALARM -OK 
! Output Alarm 

! send  ALARM 

! Remove (SP. Outpu t Alarms,  ST) 

! Tir.R  ->  DeQ(R,  SD 

! TinR  ->  rescissible’; 

1 Alarm  Input 

j 

! Awaiting  ReceiveAlarn 
! ALARM  received 

! send  ALARM -OK 

! DeQ(DP.  Alarmlr.putQ,  DT) 


i 

i 

! 

! 

i 

f 

i 

! 


Alarm  Receive 

Awaiting  ALARM 

R^ceiveAlarm 

DeQ(DP.  Receive AlannQ,  DT) 
rescissible’ ; 


* Cor.n  Open 

? 

! Awaiting  CONN-OPEN 
! Open Conn 

! send  CONN-OPEN 

! Remove(P. Connections,  T); 

! [)  TinR  =>  DeQCR,  T);  send  CONN-CLOSE  (j 

! TinR  ->  rescissible 

! Awaiting  Oper.Conr. 

! CONN -OPEN  received 

! Remove(P. Connections,  T) 

! send  CONN-REJ 

! Connection  open 

! Open Conn  & CONN -OPEN  received 

! Remove (P. Connections,  T) 

! send  CONN-CLOSE 

! StopMe  only’; 
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♦ Corn  Close 

i 

! Awaitirg  CONN-CLOSE 
! Close  Cor.:* 

! send  CONN-CLOSE 

! [)  (rescind  i Tir.R  5c  viable  correct: or)  ->  set  Connection  open; 

! Remove(P. Connections,  T)  (] 

! (rescind  & Tir.R)  ->  EteQ(R,  T) 

! (viable  ccrnection  h Tir.R)  ->  rescissibis 

! Awaiting  CloseCor.n 
! CONN-CLOSE  received 

i Remove (P. Corrections,  T);  (timeout  ->  activate  Cor.nBroLen  signal) 

! send  CONN-CLOSE 

i 

! Awaiting  CONN-OPEN  or  CONN-CLOSE 
! Awaiting  CONN-OPEN  i CloseCcr.n 

! send  CONN-CLOSE 

! Remove(P. Connections,  T) 


(ii  snatch  — awaitirg  CONN -CLOSE 
CONN-OPEN  mismatch 
send  CONN-CLOSE 
Remove(P. Corrections,  T) 

_ » . 

i 


the  Delivered  state  — Awaiting  user  ! network  delivery 
No  action’; 


•.Notes 

! rescind 

! if  not  rescissible,  do  nothing 

! stop  timing 

! local  and  remote  cleanup 

! direct  delivery 

! StopMe 
! stop  timing 

! local  and  remote  cleanup 

! no  delivery 

! deadhost 

! stop  timing 

! loca . cleanup 

! delivery  via  server 

! timeout 

l local  and  remote  cleanup 

! delivery  via  server*; 


******  - 
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Rescind Pending Evert  <- 

i 

I R3scirdPer.dlr5fi.vert  encodes  the  part  of  the  above  table 
! having  to  do  specifically  with  rescission.  First  a test  is 

i done  to  determine  if  tne  event  is  in  a rescissible  state, 

t If  it  is  then  both  network  and  local  action  are  taker.. 

! Delivery  is  done  by  the  calling  routine.  Carcellirg  message 

! transactions  where  both  sender  and  receiver  are  local  is 

! handled  specially. 

t 

• V 

EXPiUE : Transact  ion  Handle , Es  Process  :DestHar  die;  Reason Code) 

BEGIN 

DECL  Rescissible: BOOL; 

Rescissible  <- 
CASEiE. State] 

["Awaiting  XM IT" ] , 

["Awaiting  prior  MESS  completion"], 

["Awa itirg  MESS”], 

["Awaiting  ALARM"]  =>  TRUE; 

["Aw  itirg  MES3-0X" ] , 

L awaiting  ALARM -OX"  3 , 

["Awa itirg  CONN-OF-N"]  => 

Has Pending Pro tocolOutput(E) ; 

["Awaiting  CONN-CLOSE" ] => 

Has  Per.  d i r g Pro  toe  olQjtput(E)  AND 
NOT  Nu li(E. Cor.r.ec tior. ) ; 

TRUE  =>  FALSE; 

END; 

NOT  Rescissible  =>  "Unable  to  Rescind"; 

StopTimir.g(E); 

IsLocalTransactior.(E)  => 

BEGIN 

Resc ir.d Loc a 1 Even t ( E , EsProcess); 

"Event  rescinded"; 

END; 

E. State  = "Awaiting  CONN-CLOSE"  => 

BEGIN 

StopProtocolOutput(E) 

E. State  <-  "Connection  open"; 

"Event  rescinded"; 

END; 

RemoteCar.ceKE,  EsProcess, 

BEGIN 

MD(E)  = MessHandle  => 

"Message  rescinded  or  timed  out"; 
"Transaction  rescinded"; 

END); 

E. Disposition  <-  "Event  rescinded"; 

LocalCar.ceKE,  EsProcess); 

"Event  rescinded"; 

END; 
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Rescind Local Event  <- 

i 

! Rescind Local Event  handles  "Awaiting  XMIT"  rescission  where 
! both  the  sender  and  receiver  are  local.  The  source  event  is 

! rejected  and  the  destination  event  is  dequeued. 

' V 

EXPR  ( ST : Transact  ion  Hard  le , SP:  DestHar.dle) 

BEGIN 

DECL  DP:  ProcessHar.dle  LIKE 
SeizeDestHar.dleCST.Dest Process) ; 

DECL  DT: Transaction Handle  LIKE 
SeizeTrarsaction(ST.DestlD); 

ST. Di spas it ion  <-  "Evert  rescinded"; 

Reject0utputMess(3T,  ST. Disposition,  SP, 

TRUE  IE  NoDeliver); 

DeQ(DP. InputMessQ,  DT); 

Release (DP) ; 

Free(DT) ; 

END; 
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StopTrarsaction  <- 

« 

! StopTrar.sactior  encodes  the  part  of  the  above  table  having 
to  do  specifically  witn  Stop  Me.  It  car.  be  called  with 
T in  any  state.  Both  network  ar.d  local  action  are  taken. 

; No  delivery  is  done,  since  the  process  is  terminated. 

Local  message  output  transactions  are  treated  specially 

• (activating  messages  "Awaiting  prior  MESS  completion"  via 
RejectOutputMess  is  avoided). 

• V 

EXPR(T : Transact ion Handle,  Ts Process :Dest Handle) 

BEGIN 

IsLocalTransactior.(T)  => 

StopLocalTrar.saction(T,  TsProcess) ; 

T. State  = "Connection  open"  => 

BEGIN 

Send Clo se Cor r.(T,  "Process  terminated",  TsProcess); 

Remove(Ts Process. Connections,  T): 

END;  ’ ’ 

IsPassiveTrar.saction(T)  =>  NOTHING; 

StopTimirg(T) ; 

Drrr!ie^r‘C2^  ’ TsProcess,  "Process  terminated"); 

BEGIN 

T. State  = "Awaiting  MESS-OX"  OR 
T. State  = "Awaiting  X-1IT"  OR 
T. State  = "Awaiting  prior  MESS  completion"  => 

DeQ (Ts Process. CutputMessQ,  T); 

Local Cancel (T,  TsProcess); 

END; 

END; 

StopLocalTrar.sactior.  <- 

t 

! Stop  handles  message  transactions  where  both  the  sender  and 
receiver  are  local.  The  source  transaction  is  dequeued  if 
. owned  by  the  stopping  process,  otherwise  it  is  rejected  and 
j delivered.  The  destination  transaction  is  dequeued. 

* */ 

EXPR(T .‘Transaction Handle , P: Dest Handle) 

BEGIN 

DECL  IsSer.der :B00L  LIKE  T. State  = "Awaiting  XMIT"; 

DECL  Matchir.gP;ProcessHandle  LIKE 
SeizeDest Hard le( BEGIN 

IsSer.der  =>  T.DestProcess; 

T. Source Process ; 

END); 

DECL  MatchingT :TransactionHar.dle  LIKE 
SeizeTransaction( BEGIN 

IsSer.der  =>  T.DestID; 

T. Source ID; 

END); 


BEGIN 
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Is  Sender  => 

BEGIN 

DeQ(P.OutputMessQ,  T); 

DeQ(  Matchir.gP.  Ir.putMessQ,  Matchir.gT) ; 

END; 

MatchirgT. Disposition  <-  "Process  terminated"; 

Re jectOutputMess( Matchir.gT,  Matchir.gT. Disposition, 
Matchir.gP,  TRUE  IE  NoDeliver); 
DeCKP.InputMessQ,  T); 

Deliver(  Matchir.gT,  Matchir.gP); 

END; 

Rele3se(  Matchir.gP ) ; 

Free(MatchirgT); 

END; 

HostDeadTrar.saction  <- 

i 

! HostDeadTrar.sactior.  er.codes  the  part  of  the  above  table 
! having  to  do  specifically  with  the  failure  of  ar.  MSG. 

! Only  local  action  is  taker.,  ar.d  the  result  is  delivered  via 

! server.  If  the  owr.ir.g  process  car.r.ot  be  seized  FALSE  is 

! returned . 

i 

• «/ 

EXPR(T : Transact ion Handle ; BOOL) 

BEGIN 

IsPassiveTrar.sactior.(T)  =>  TRUE; 

DECL  TsProcess  iDestHar.dle  LIKE 

TestSeizeDestHar.dle(Owr.irgProcess(T) ) ; 

Null(TsProcess)  =>  FALSE; 

StopTimir.g(T) ; 

DECL  Ts  Old  St  ate:  RoasorCode  LIKE  T. State; 

T. Disposition  <-  "Host  died"; 

LocalCar.ceKT,  TsProcess); 

Deliver Cancel (T,  TsProcess,  TsOldState); 

Release(Ts  Process) ; 

TRUE; 

END; 
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i 

i 

i 


i 

i 

i 


TimeoutTrar.sactlor.  <- 


» 


! 

j 


TimeoutTr ansae tior.  encodes  the  part  of  the  above  table 
having  to  do  specifically  with  timeout.  Both  ret  work  and 
local  action  are  taken,  and  the  result  is  delivered  via 
server.  If  the  owning  process  carrot  be  seized  FA Lot  is 
returned.  Cancelling  message  transactions  where  both  sender 
and  receiver  are  local  is  handled  specially. 


*/ 

EXPR(T:Trarsac tier. Handle;  BOOL) 

BEGIN 

DECL  Ts Process -.DestHar.dle;  . 

IsLocalTransactior.(T)  =>  TimeoutLocalTrarsactior.(T); 
TsProcess  <-  TestSeizeDestHurdle(Ownir.gPrccess(T)) ; 
Null (Ts Process)  =>  FALSE; 

DECL  TsOldState : StateCode  LIKE  T. State; 


RemoteCar.ceKT,  TsProcess, 

BEGIN 

T. State  = ” Awaiting  CONN-OPEN”  OR 
T. State  = 

"Awaiting  C0NN^)PEN  or  CONN-CLOSE”  => 

'•Timed  out  waiting  for  your  CONNECTION-OPEN"; 
IsMessHandle(T)  => 

"Message  rescinded  or  timed  out"; 

"Transaction  timed  out"; 

END); 

T. Disposition  <-  "Transaction  timed  out"; 

LocalCar.ceKT,  TsProcess); 

TsOldState  = "Awaiting  CloseCorr."  ->  , . , 

T.Op  <-  "StopMe”  /*  'for  connection-broken  signal  ; 

DeliverCancelCT,  TsProcess,  TsOldState); 

Release (TsProcess) ; 

TRUE; 

END; 


TimeoutLocalTransactior.  <- 
» 

! TimeoutLocalTransactior.  handles  message  transactions  where 
i both  the  sender  and  receiver  are  local.  The  source 

! transaction  is  rejected,  the  destination  transaction  is 

! dequeued  and  the  source  transaction  is  delivered.  If  the 

! owning  process  cannot  be  seized  FALSE  is  returned. 

i 

: */ 

EXPR(T :Transactior.Har.dle;  BOOL) 

BEGIN 

DECL  IsSender :B00L  LIKE  T. State  = "Awaiting  XMIT"; 

DECL  SP:  ProcessHar.dle  LIKE 

TestSeizeDestHar.dle(T.SourceProcess) ; 

NulI(SP)  =>  FALSE; 

DECL  DP:ProcessHandle  LIKE 

Test SeizeDest Hard le(T.Dest Process) ; 

Null (DP)  =>  [)  Release(SP);  FALSE  (]; 
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DECL  Matchir.gT:  Tr  ansae  tior.Hsr.dle  LIKE 
Te  st  Se  i ze Tr  an  s ac  t ior.  ( BEG  I N 

IsSer.dsr  =>  T.DestID;  . 
T.SourcelD; 

END);  _ 

Null(Matchir.gT)  =>  C)  Release(SP);  Release(DP);  FALSt  (J; 
DECL  ST :Trar.sactior Handle  LIKE 
[)  IsSerder  =>  T;  Matchir.gT  (]; 

DLCL  DT iTrar.sactionHardle  LIKE 
[)  IsSer.der  =>  Matchir.gT;  T (3; 

ST, Disposition  <-  DT. Disposition  <-  ’’Event  timed  out”; 
ReiectOutputMessCST,  ST. Disposition , SP, 

TRUE  IE  NoDeliver); 

DeQ(DP. IrputMsssQ,  DT); 

Deliver(ST,  SP); 

Release(SP) ; 

Release(DP) ; 

Free(  Matchir.gT ) ; 

TRUE; 

END; 


t 


Abstract  Model  of  MSG 
Module  CANCEL 


135 


LoealCancel  <- 

i 

! LoealCancel  encodes  the  local  action  part  of  the  above  table. 
! In  general  this  consists  of  daqueuirg  the  transaction  from 

! the  proper  process  queue. 

i 

’ V 

EXPR(T:Trar.sactior. Handle,  TsProcess.-DestHandle) 

CASE[T. State] 

[’’Awaiting  MESS -OX”], 

[’’Awaiting  XMIT”], 

["Awaitir*,  prior  MESS  completion"]  => 

RejectOutputMessCT,  T. Disposition , Ts Process, 

TRUE  IE  NoDeliver); 

[’’Awaitirg  HOLD-OX”],  [’’Held  by  sender”]  => 

DeQCTs  Process.  Input Mess Q,  T); 

[’’Awaiting  retransmission”]  => 

BEGIN 

DeQCTs  Process.  Ir.putMessQ,  T); 

RemitBufferCTsProcess , T); 

END; 

[’’Awaiting  ReceiveMess"]  => 

BEGIN 

DeQCTs Process. InputMcssQ,  T); 

CreditBufferCTsProcess , T); 

END; 

["Awaitirg  MESS”]  => 

BEGIN 

NOT  T.IsGer.eric  =>  DeQCTs  Process.  ReceiveMessQ,  T); 

DECL  G: Generic Handle  LIKE 

Seize(GenericTable[TsProcess.Name.GenericName] ) ; 

DeQCG. ReceiveMessQ,  T); 

Release(G); 

END; 

["Awaiting  ALARM-OX”]  => 

Remove (Ts Process. Output Alarms,  T); 

["Awaiting  Receive Alarm”]  => 

DeQ  ( Ts  Process.  Ir.  putAl  a rmQ,  T); 

["Awaiting  ALARM’’]  r>  DeQCTs  Process.  ReceiveAlarnQ,  T); 
["Awaiting  CONN-OPEN’’], 

[’’Awaiting  OperConr."], 

["Awaiting  CONN-CLOSE’’] , 

["Awaiting  CloseCor.n”] , 

["Awaiting  CONN-OPEN  or  CONN-CLOSE’’] , 

[’’Mismatch  — awaiting  CONN-CLOSE’’]  => 

RemoveCTs Process. Connections,  T); 

["Delivered"]  =>  NOTHING; 

TRUE  =>  MSGErrorC 'Bad  cancel  state'); 

END; 
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RsmoteCar.cel  <- 


i 

i 

i 

i 

i 

» 


RemoteCar.cel  encodes  the  network  action  part  of  the  above 
table.  In  general  this  consists  of  sending  a protocol  item, 
or  changing  or  removing  a protocol  item  ready  to  be  sent. 


*/ 

EXPR  (T : Tr  ar.sac  t ion  Hand  le , 

Ts Process : Dest Handle , 

Why : Reason Code) 

CASE[T. State] 

[’’Awaiting  MESS-OX"]  => 

BEGIN 

Has  Pending Protocol CUtput(T)  => 

BEGIN 

NOT  Null(T.DestlD)  => 

ChangeProtocolOutputCT,  "MESS-CANCEL" , Why); 
StopProtocolOutput(T) ; 

END; 


END; 

[’’Awaitirg  XMIT"]  => 


BEGIN 

Has  Pend  ir.gProtocolOutput(T)  => 

Char g a Protocol Outpu t(T,  ”M ESS -CANCEL” , Why); 
SendMESSX CANCEL (T,  ’Why); 

END; 

[’’Awaiting  HOLD-OX”]  => 

Has Pending Protocol Qjtput(T)  -> 

ChangeProtocolOutputCT,  "MESS-REJ",  Why) ; 
[’’Held  by  sender”]  =>  Ser.dME3S\REJ(T,  Why); 
["Awaiting  retransmission”]  => 

Has  Pending  Protocol  CXitput(T)  -> 

ChangeProtocolOutputCT,  ’’MESS-REJ",  ’Why); 


["Awaiting  ALARM -OX"]  => 

Has  Pend  ir.gProtocolCXitput(T) 
[’’Awaiting  CONN-OPEN"]  => 


->  StopProtocolOutput(T); 


B^Has  Pending  Pro  toco  lOutput(T)  =>  Stop  Protocol  Cbtput  (T ) ; 

SendCloseConnCT,  Why,  TsProcess); 


end; 

["Awaiting  Open Conn”]  =>  RejectConnCT,  Why,  TsProcess); 
[’’Awaiting  CloseConn"]  => 

SendCloseConnCT,  Why,  TsProcess); 

TRUE  =>  NOTHING; 

END; 
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IsPassiveTrar.saction  <- 

t 

! IsPassiveTrar.saction  detennir.es  whether  ar.y  cancel  action  need 
! be  taken.  If  the  transaction  is  awaiting  local  delivery  it 

! can  be  ignored. 

i 

* */  EXPR(T:TransactionHardle;  BOOL)  T. State  It  “Delivered"; 
IsLocalTransactior.  <- 

t 

! IsLocalTransactior.  determines  whether  a transaction  is  a 
! message  transaction  with  both  sender  and  receiver  local. 

' */ 

EXPR(T:Trar.sactior. Handle ; BOOL) 

T. State  = “Awaiting  XMIT"  AND 
T.  State.  Dest  Process.  Bast  = Local  Host  OR 
T. State  = "B3ld  by  sender"  AND 
T.  Source Process. Bast  = LocalBast; 

Ownir.gProcess  <- 
» 

! Ownir.gProcess  returns  the  process  r.ane  of  the  process  for 
! 'which  the  given  transaction  was  created. 

i 

» »/ 

EXPR (T :Transact ion Handle ; ProcessName) 

CASE[T. State] 

["Awaiting  HOLD-OX"], 

["Held  by  sender"], 

["Awaiting  retransmission"] , 

["Awaiting  ReceiveMess"] , 

["Awaiting  MESS"], 

["Awaiting  ReceiveAlarm" ] , 

["Awaiting  ALARM"]  =>  T. Dest Process ; 

TRUE  =>  T. Source  Process ; 

END; 

Has Pending Protocol Out put  <- 

* 

! Has  Pending  Protocol Cut put  determines  whether  a transaction 

! has  a protocol  item  waiting  to  be  sent. 

• V 

EXPR (T: Transaction Hand le ; BOOL)  NOT  NullCT. Protocol Command) ; 


Abstract  Modal  of  MSG 
Module  CANCEL 


138 


ChangeProtocolOutput  <- 

t 

! Change  Pro tocolOutput  charges  the  typa  of  protocol  item  waiting 

! to  be  sent  (to  or.e  appropriate  for  cancellation). 

! 

1 »/ 

EXPR(T  :Transactior.Har.dle, 

Action : Protocol  Code , 

WhyiReasonCode) 

[)  T. Protocol Connand  <-  Action;  T.  Reason  <-  Why  (J; 

StopProtocolOutput  <- 

i 

! StopProtocolOutput  stops  the  sending  of  a protocol  item 
! waiting  to  be  sent  by  dequeuing  its  transaction  from  the 

! network  delivery  queue. 

i 

• »/ 

E XPR  (T : Tr  ar.  s ac  t ior.  Handle) 

BEGIN 

DECL  HC: Host Code  LIKE  T. Dest Process. Host; 

DECL  HHiHostHar.dle  LIKE 
FOREACH  H IN  HostS  DO  HC  = H.Bost  =>  H END; 

DECL  HQ : Que  ue ( Tr  an  sac  t ion ) LIKE 
HH. Del iver Server . Del iveryQ; 

Seize(HQ) ; 

DeQCHQ,  T); 

Release(HQ); 

END; 

Del iver Cancel  <- 

» 

! Del iver Cancel  determines  whether  a cancelled  transaction  need 
! be  delivered  (via  server),  and  if  so  delivers  it, 

j 

' */ 

EXPR (T : Transaction  Handle , 

TsProcess : DestHandle , 

TsOld State : Reason  Code) 

CASECTsOldState] 

["Awaiting  MESS-OX"], 

["Awaiting  XMIT"], 

["Awaiting  prior  MESS  completion"], 

["Awaiting  MESS"], 

["Awaiting  ALARM-OX"], 

["Awaiting  ALARM"], 

["Awaiting  CONN-OPEN"], 

["Awaiting  CONN-CLOSE"], 

["Awaiting  CloseCor.r."] , 

["Awaiting  CONN-OPEN  or  CONN-CLOSE"]  => 

Deliver(T,  TsProcess); 

TRUE  =>  NOTHING; 

END; 


i 
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t 

i. 

i 

! 

t 

i. 

t . 
i 

t 

i 

i 

i 


Timer  routines 


Deadlines  are  absolute  fixed  points,  not  irtervals. 

The  front  of  the  timer  queue  is  the  evert  which  will  time  out  earlies 
The  FOREACH  loop  runs  from  the  front  of  the  queue  to  the  back.'; 


StartTimir.g  <- 

t 

t StartTimirg  takes  a transaction  and  adds  it  to  the  timer 
i queue.  If  a new  deadline  is  supplied  via  NewTimer,  it  is 

i assuned  to  be  a relative  irterval,  and  is  converged  to 

i absolute  form.  The  timer  queue  is  scanned,  the  transaction 

t inserted  and,  if  the  transaction  is  at  the  front  of  the 

i queue,  the  timer  process  is  notified. 

i 

» */ 

EXPR(  NewEr.tr  y : Transaction  Handle,  NewTimer:  Interval) 

BEGIN 

Sei ze ( Timer Q) ; 

DECL  IsAtFror.t  :300L  LIKE 
Null  (Timers ) OR 

NewEntry. Deadline  LT  Front(TimerQ) .Deadline; 

NOT  Null  (NewTimer)  -> 

NewEntry. Deadline  <-  Make  Inter valAbsolute( NewTimer) ; 

BEGIN 

Null(TimerQ)  =>  FALSE; 

FOREACH  Er.try  AT  Es Location  FromFror.tOf  TimerQ 
DO 

NewEr.try  .Deadline  LT  Er.try  .Deadline  => 

[)  EnQAtCEs Location,  NewEntry);  TRUE  (]; 

FALSE; 

END; 

END  0>  EhQ(  Timer  Q,  NewEr.try); 

IsAtFront  ->  SIGNAL(TimerSignal) ; 

Release(TimerQ) ; 

END; 
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StopTirairg  <- 

I 

! StopTimir.g  takes  a transaction  and  removes  it  from  the  timer 
! queue. 

! 

* V 

EXPR  (Old  Entry:.  Tr  ar.  sac  tior.Hardle) 

BEGIN 

Seize(TimerQ) ; 

DeQ( Timer Q,  0]d  Entry); 

Release(TimerQ) ; 

END; 

TimeoutHar.dler  <- 

! TimeoutHar.dler  waits  for  timeouts  and  cancels  transactions. 

! It  waits  until  the  deadline  of  the  front  entry  of  the  timer 

! queue  expires.  It  also  waits  to  be  signalled  from 

! StartTimir.g  that  a new  entry  has  beer,  put  on  the  front  of 

! the  timer  queue.  When  a transaction  times  out  an  attempt  is 

! made  to  seize  it  and  car  el  it.  If  this  is  successful  the 

! transaction  is  removed  fr_  ' the  timer  queue.  If  this  fails, 

! TimeoutHar.dler  waits  a brief  interval  and  tries  again. 

i 

• V 
EXPRO 

REPEAT 

Seize(TimerQ) 

/*  ’This  may  wait  for  StartTioir.g  or  StopTimiirg  to  Release.'; 
DECL  TimeoutSigral :SigralType  LIKE 
BEGIN 

Null(TimerQ)  =>  NullSigr.al; 

StartClockCBEGIN 

Front(TimerQ) .Deadline  LT  CurrentTxmeO  => 

Makelr.tervalAbsolute(SeizeWait) ; 

Front(TimerQ). Deadline; 

END); 

END; 

Release  (TimerQ) ; 

DECL  WaitSigr.al  :SignalType  LIKE 
WAIT( { Timer Signal,  TimeoutSigral  }); 

BEGIN 

WaitSigr.al  = TimerSignal  =>  StopClock(TimeoutSignal) » 

Seize(TimerQ) ; 

FOREACH  Er.try  AT  EsLocation  FromFror.tOf  TimerQ 
DO 

Currer.tTimeC ) LT  Er.try  .Deadline  =>  NOTHING; 

TestSeize(Entry)  //>  NOTHING; 

TimeoutTrarsactior.(  Entry)  ->  DeQAt( EsLocation) ; 

Free( Entry) ; 

END; 

Release(TimerQ); 

END; 

END; 


Abstract  Nbdel  of  MSG 
Module  REMOTE 


141 


» 

; 

! 

! 

» 

! 


MSG-MSG  protocol  format  def ir.itior.s 


! The  various  fields  of  protocol  items  ir.put  from  the  network  must  be 
Jcor.verted  from  8-bit  byte  agglomerations  into  usable  objects,  and  the  reverse 
!must  be  dore  or  output.  The  following  operators  iefir.e  and  perform  the 
! conversion , allowing  the  mass  of  network  data  to  be  accessed  as  a data 
Istruc ture. 

! The  FORMAT  operator  defines  the  simulated  data  structure  of  the  protocol 
! items,  with  each  field  being  given  a name,  a mode  and  a length  in  bytes. 

! Same  field  specifications  vary  from  this  general  form,  ard  employ  the 

! following  operators  in  their  definition.  The  “ operator  irdicates  that  a 
!field  is  actually  composed  of  a runber  of  subfields,  which  are  defined  in  the 
! FORMAT  that  ” takes  as  its  argument.  Trie  * operator  indicates  that  a field 
1 requires  special  processing  to  convert  it,  with  * taking  as  its  argument  the 
! routine  to  do  the  processing.  The  — operator  indicates  that  a field  is  rot 
! converted  by  FORMAT  at  all,  but  is  included  for  documentation  purposes. 

! Tne  {?  operator  irdicates  a field  that  may  be  assigned  directly  to  and 
!from  an  appropriate  internal  data  structure.  Such  direct  assignments  are 
! performed  with  the  <!',  arj  {!>  operators. 

! The  ! operator  is  used  to  reference  individual  fields,  the  format  to 

!wh.ich  the  | applies  having  been  chosen  by  either  the  <!!,  !!>  or  | operator. 

« . 

i 

Header  <-  FORMAT  (Length:  Short  Ir.t  (2 ) , Command : ProtocolCodeC  1 )) ; 


j Mess-related  formats’; 

MessFomat  <- 

FORMAT (Length : Short Irt ( 2 ) , 

Command : Protocol Code ( 1 ) , 
SourceID:2  Transaction ID(2) , 
Oes^ID:^  Transaction ID (2) , 
FirstByte:SnortIr.t(  1 ) , 

IsGeneric:?  BOOL, 

IsSequenci‘d:2  BOOL, 

Is  Marked :3  BOOL, 

No  Hold  BOOL, 

HoldCk:£  BOOL, 

NoQ.VaitiBXL, 

Source Process: Q “ MSGProcessName , 
Dest Process: 3 “ MSGProcessName, 
Text: — ); 


-rr'n^i.fe^.rrw 
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MessOkFormat  <- 
FORMAT  (Length:  Short Ir.t  (2) , 

Command : ProtocolCode(  1 ) , 
SourcelD:2  TransacticnID(2) , 
Source  Process:  2 “ MSGProcessName, 
Dest Process :2  ~ MSGProcessNane) ; 

MessRejFonnat  <- 
FORMAT  (Lei  gth:  Short  Ir.t  (2) , 

Command : Protocoled de(  1 ) , 
SourceID:2  Trar.sactior.ID(2) , 
Reason :2  Rea^rGadeC 1 ) , 

Source Process: 2 MSGProcessName, 
DestFrooess:2  ~ MSGProcessName) ; 


Mess Ho Id  Format  <- 
FORMAT  ( Ler  g th : Sho  r t Ir  t ( 2 ) , 

Command:  Protocol Gxle(  1)  y 
SourceID:2  Trar.sactior.ID(2) , 
DestID:2  7rar.33Ctior.ID(2) , 

Source Process : 3 " MSGProcessName , 
Dest  Process : 2 ~ MSGProcessName); 

HoldOkFor:nat  <- 
FORMAT (Ler.gth:SvhortIrt( 2) , 

Command : ProtocolCode(  1 ) , 
SourceID:2  Trar.sactior.IDC2) , 

Dest  ID: 2 Trarsactior.lD(2) , 

Source Process: Q ~ MSGProcessName, 
DestProcess :2  * MSGProcessName) ; 

Mess Cancel  Format  <- 
FORMAT  ( Ler.g  th : Short  Ir.  t ( 2 ) , 

Command : Protocol CodeC 1) , 
SourceID:2  Trarsactior.ID(2) , 
DestID:2  Transaction  ID (2) , 

Reason: 2 Reasor.CodeC  1 ) , 

Source  Process: 2 ~ MSGProcessName , 
DestProcess :2  " MSGProcessName); 

XmitFormat  <- 

FORMAT  (Length:ShortIr.t(  2) , 

Command : Protocol  God  e ( 1 ) > 
SourceID:2  Transaction ID(2) , 
DestID:2  Trar.sactionID(2) , 

Sour ce Process : 2 “ MSGProcessName, 
DestProcess:2  *“  MSGProcessName); 
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! Alarm-related  formats'; 

AlannForn  - 

FORMAT  (Ler..  . 5hortIr.t(2) , 

Comm..  u : FrotocolCodeC  1 ) , 

Sour  ce  ID:  0 Trar.sactior.ID(2) , 
Alarm:?  Alar:nCode(2) , 

Source  Process : 2 ~ MSG Process Name, 
DestProcess:?  ~ MSGProcessName) ; 

AlarmOk Format  <- 
FORMAT  (Length:  Snor t Ir t ( 2 ) , 

Command : Protocol  Code  ( 1 ) , 
SourcelD:?  Transactior.ID(2) , 
Source Process: 2 ~ MSGProcessName, 
DestProcess:?  “ MSGProcessName) ; 

Alarm Re j Format  <- 
FORMAT  ( Ler.  g th : Shor  t Ir  t ( 2 ) , 

Command:  Protocol Gode( 1) , 
SourcelD:?  Trar.sactior.ID(2) , 
Reason:?  Reason  Code ( 2) , 

Source Proc ess : 2 ~ MSGProcessName, 
DestProcess:?  “ MSGProeessNane) ; 


! Cor.r. -related  formats'; 

Cor.r.Oper  Format  <- 
FORMAT  ( Ler  g th : Short  In  t ( 2 ) , 

Command : ProtocolCode( 1 ) , 
SourcelD:?  TransactionID(2) , 
DestID:?  TransactionID(2) , 

Corn  ID  :§  Cor.r.IDCode(2) , 
Type\duplex:BOOL, 

Type\ser.d:BOOL, 

TypeXreceive : BOOL , 

Type\ Server TELNET:300L, 
TypeMJserTELNET : BOOL , 
Cor.nBytesize:?  Short  In  t(  1) , 
RemoteSocket:?  Ir.teger(3), 

Source  Process: 2 " MSGProcessName, 
DestProcess:?  “ MSGProcessName); 
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Cor.r.CloseFormat  <- 

F0RMAT(Lergth:ShortIrt(2), 

Command : ProtocolCodeC  1 ) , 
SeurceID:§  Transaction ID(2) , 
DestID:2  Trar.sactionID(2) , 

Corn ID :2  Conr.IDGode(2) , 

Reason : 2 Reasor.CodeC  1 ) , 

Source  Process : Q ~ MSG  Process Name, 
DestProcess :2  " MSGProcessNamo) ; 

Conn Re j Format  <- 

FORMAT (Ler.  g th : Snorl  In t ( 2 ) , 

Command : Protocol Code( 1) , 
SourcelD:?  Transaction  ID (2 ) , 
DestID:2  Trar.sactionID(2) , 

Corn  ID: 2 Conr.IDCode(2) , 

Reason : 2 Reason CodeC 1 ) , 

Source Proc ess : 2 " MSGProcessName, 
Dest  Process : 2 ~ MSGProcessNane) ; 


! Other  formats ’ ; 

No Op Form at  <- 

FORMAT  (Length:  Short  Ir.t  (2) , Command:  Pro  tocoiCode(  1) ) ; 

EchoFonnat  <- 

FORMAT  ( Length : Short  Ir.t  (2) , 

Command : ProtocolCodeC 1 ) , 

Data:ANY(D); 

EchoReplyFormat  <- 

FORMAT  ( Ler.g  th : Short  Ir.t  (2 ) , 

Command : ProtocolCodeC 1 ) , 

Data:ANY(  1) ); 

ExpFormat  <- 

FORMAT  (Length:  Short Ir.t(2), 

Command : ProtocolCodeC 1 ) , 

Function :ANY( 1) ); 


t 
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SendStatusFonnat  <- 
FORMAT ( Ler gth: Short  Ir.t( 2) , 

Command : ProtocolCodeC 1 ) , 
SourceID:Trar.sactior.ID(2) , 
Source  Process : ' MSCProcessName, 
Dest Process:'  MSGProcessNane) ; ' 

StatusOkFormat  <- 
FORMAT (Ler.gth:  Short Ir..t (2) , 

Command : Pro  toco  1 Code  ( 1 ) , 
SourcelD: Transact ion  ID (2) , 
SourceProcess : ~ MSGProeessNam? , 
Dest Process:'  MSGProcessNane, 
Status:  — ); 

Status Re j Format  <- 
FORMAT ( Long th : Snor  t In  t ( 2 ) , 

Command : ProtocolCodeC  1) , 

SourceID:Trar.sactior.ID(2) , 

Reason : Reason Gode(2) , 

Source P ‘ocess : ~ MSGProcessNane , 
Dest Process : ' MSGProcessName)*/ 

CloseFormat  <- 
FORMAT  (Length:  Short  Ir.t(2) , 

Command : ProtocolCodeC 1 ) , 

Reason : Reason Code (2) ) ; 

SynchForm3t  <- 
FORMAT  (Ler  gth : Short  Ir.t  (2) , 

Comm  and  .-Protocol  Code(  1), 

My  Incarnation : Short  Ir.t(2) , 

Your Incarnation : Short  In t ( 2 ) , 
Version : Short  In  t (2 ) ) ; 

Pt cl Err Form at  <- 
FORMAT ( Ler gth: Short  In t (2) , 

Command : ProtocolCodeC 1 ) , 

Error  Code:  Short  In t(2) , 

Bad Transaction: — ); 
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! The  ProcessName  format.  ; 

MSGProcessName  <- 
FORMAT (Incarnation  :$  3hortIr.t(2) , 

Instance:?  ShortInt(2), 

Ger.ericNane:?  * Ger.ericClass) ; 

GenericClass  <- 

i 

! GenericClass  is  the  routine  invoked  to  parse  the  Gor.ericName  field. 

! The  Generic  Name  field  has  a conditional  structure,  unlike  other 

! fields.  If  the  first  byte  of  the  field  is  greater  than  127  then 

! it  is  a generic  code,  and  there  is  no  more  to  the  field.  If  it  is 

! less  thar  or  equal  to  127  it  is  the  length  of  a text  string  naming 

! the  class,  with  the  text  bytes  following.'; 

NetBuffer  <- 

i 

! NetBuffer  is  the  data  structure  use!  to  buffer  ir coming  and 

! outgoirg  network  lata.  l>.ta  is  the  actual  network  data 

1 (2273  is  the  maximum  n.unber  of  bytes  in.  the  longest  possible 

! item).  Channel  is  the  network  channel  used  for  transfers  to 

! and  from  the  buffer.  Host  is  the  target  host.  Scan  is  3 

! pointer  to  the  last  byte  read  or  written  (it  is  advanced 

! by  the  < i i , jj>  and  | operators  as  they  process  fields). 

! Read  points  to  the  last  byte  RECEIVEd  from  the  network. 

i 

' V 

'STRUCTCData: VECTORC2273,  NetByte) , 

Channel : Channel Handle , 

Host:HostCode, 

Scan: Integer , 

Read  .-Integer)  • ; 

Net Receive Item  <- 

» 

! Net Receive Item  reads  a complete  protocol  item  into  the  NetBuffer  passed 

! to  it.  It  RECEIVES  the  first  two  bytes  (the  length  of  the  item)  and 

! then  RECEIVES  the  rest.  If  either  a protocol  error  is  detected 

! or  a channel  error  occurs,  an- error  Reasor.Code  is  returned.’; 
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NetSer.dlte-n  <- 

i 

! N2tSer.dIte-n  SENDs  the  protocol  iten  ir.  the  Net  Buffer  oass-d  to  it 

! If  a charnel  error  occurs,  FALSE  is  returned.’; 


W 


t 
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! Protocol  input  routines 


« . 

i 

Protocol In put  <- 

* 

! Protocol Input  waits  until  either  there  is  a new  channel  for 
• it  to  listen  to,  or  there  is  activity  on  one  of  the  ch.ar.nels 

! already  assigned  to  it.  When  a channel  becomes  active,  the 

! routine  inputs  a protocol  item  and  dispatches  to  the  proper 
! specialized  it an  handler. 

i 

» V 

EXPR (Ego : Server Handle) 

BEGIN 

DECL  B: NetBuffer  LIKE  AllocateNetBuffer( ) ; 

REPEAT 

BEGIN 

DECL  Signalor  :UNICN(GiannelHar.dle,  Signal  Type)  LIKE 
WAIT({  Ego.Cnar.nelS,  Ego.  WakeUpSigr.al  }); 

Signalor  = Ego. Wake Up Signal  =>  NOTHING; 

B. Channel  <-  Sigralor; 

B.fost  <-  GetHastFromOiar.neKB. Channel); 

DECL  Result: Reasor.Code  LIKE  NetReceiveIten( 3) ; 

Result  = "Protocol  Error"  =>  ProtocolError(B) ; 

Result  = "Channel  Error"  => 

BEGIN 

DECL  LocalSocket :3jc ket  LIKE 
Get  Soc  ke  t Fr  om  Char  r.  e 1 ( B . Char.r.  el); 

CHCL0SE(B. Channel); 

Deass  igr.MSG  Input  Socket  (Local  Socket) ; 

Seize(Ego) ; 

Remove (Ego. Channels,  B. Channel); 

Null(Ego. Channels)  => 

BEGIN 

DECL  Restart: Cor.tactHar.dle  LIKE 
Allocate(  Cor.  tact  Hand  le ) ; 

DECL  ThisHost.-HostHar.dle  LIKE 
SeizeHost(B.Host) ; 

Restart. Protocol Command  <-  "Start  ICP"; 

Restart. Remotefost  <-  ThisHost; 

Deliver(Restart , ThisHost); 

Release( Restart); 

Release(ThisHost) ; 

END; 

Release(Ego) ; 

END; 

!!  Header; 

CASE[ ! Corrmar.d] 

["MESS"]  =>  InputMess(B) ; 
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["MESS-OX"]  =>  Ir.putMessOkCB) ; 
["MESS-REJ"]  =>  Ir.putMcssRejCB); 
["MESS-HOLD"]  =>  Ir.putMcssHoldO) ; 
["HOLD-OX"]  =>  Ir.putHoldOk(B) ; 
["MESS-CANCEL"]  =>  Ir.putMessCar.ceK B) ; 
["WIT"]  =>  Ir.putX-nit(B); 

["ALARM"]  =>  Ir.putAlarn(B) ; 

["ALARM"]  =>  Ir.putAlarmOk(B); 

[ "ALARM-RE J"]  =>  Ir.putAlannRaj  ( B) ; 
["CONN -OPEN"]  =>  Ir. ?u t Corn Cper. ( B ) ; 
["CONN-CLOSE"]  =>  Ir.DUtCcr.rCloseC 3) ; 
["CONN-REJ"]  =>  Ir.putCor.r.Rej(B) ; 

TRUE  =>  ProtocolError(B); 

END; 

END; 

END; 

END; 


i 
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t 

! The  following  routines  parse  protocol  items  ar.d  convert  them  to  the 

! appropriate  internal  data  structures.  They  verify  lengths,  generic 

! codes  and  incarnation  r.unbers,  and  supply  host  information. 

t . 

» 


i 

i 

i 

i 


InputMess  <- 

* 


InputMess,  in  addition  to  the  usual  input  functions: 
produces  a MessHur.dle, 
converts  tha  NoOWait  field, 
verifies  specif ic/ger.eric  consistency, 
and  moves  the  message  text  (via  Ir.putMessText)  from  the 
NetBuffer  irto  the  MessHur.dle.  If  Ir.putMessText  cannot 
allocate  storage  for  the  text,  it  is  left  r.ul1 . 


’ */ 

EXPR(B:  NetBuffer) 

BEGIN 

DECL  MB:MessBlock; 

MB  <! ! Mess Form at ; 

M3.CWait  <-  NOT  i NoCWait; 

B.Scar.  //  ! FirstByte  =>  Protoco  1 Error ( B) ; 
EncodeGer.ericClass(M3.SourceProcess .GenericName)  //> 

Protocol  Error  (B) ; 

EncodeGenericClass(MB. DestProcess .GenericName)  //> 

Protocol Error(  B) ; 

MB. Scurce Process. Hast  <-  B.H-'st; 

MB. DestProcess. Bast  <-  LccalBast; 

DECL  MH: MessHur.dle  LIKE 

Allocate( Mess Handle,  MB)  /*  'implicit  Seize'; 

MH. DestProcess .Incarnation  0 Local Incarnation  => 

BEGIN 

Send  M ESS\  RE  J ( MH , 

"Bad  incarnation  number  on  destination  process"); 

Release(MH); 

END; 

BEGIN 

Null(MH. DestProcess. Instance)  => 

NOT  MH.IsGer.eric  OR  MH.  IsSequenced  OR  MH.IsMarked; 

MH. IsGeneric  OR  QWait; 

END  => 


BEGIN 

SendMESS\REJ(MH, 

"Destination  r.ame/hardling  - 


mismatch") ; 

Release(MH) ; 

END; 

MH.TextLer.gth  <-  ! Length  - ! FirstByte; 
InputMessText(B,  MH); 

EhQInputMess(MH) ; 

Free(MH); 

END; 


generic/specific 
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InputMessOk  <- 
EXPR(B:NetBuffer) 

BEGIN 

DECL  MB: Mess Block; 

MB  <J!  MessO«<  Format; 

Format  Error  (3,  MB)  =>  NOTHING; 

MB. Source Process .Bast  <-  Local  Bast 
MB. Dest Process. Bast  <-  B.Bast; 
RecordMS53\0:<(M3); 

END; 

InputMessRej  <- 
EXPR(B: NetBuffer) 

BEGIN 

DECL  MB: Mess  Block; 

MB  <!J  MessRej Format; 

Format Error( 3,  MB)  =>  NOTHING; 

MB.  Source  Process. Host  <-  Local Host 
MB. Dest Process. Bast  <-  B.Bast; 
RecordMESS\REJ(MB) ; 

END; 

InputMessHold  <- 
EXPRCB: NetBuffer) 

BEGIN 

DECL  MB: Mess  Block; 

M3<!|  Mess Ho Id Form at ; 

Forma  tErrorCB,  MB)  =>  NOTHING; 

MB. Source Process. Host  <-  LocalHost 
MB. Dest Process. Bast  <-  B.Bast; 
RecordMESS\HOLD(MB) ; 

END; 

InputHoldOk  <- 
EXPRCB: NetBuffer) 

BEGIN 

DECL  MB: Mess Block; 

MB  <|  ’ HoldOkFormat ; 

FormatErrorCB,  MB)  r>  NOTHING; 

MB. Source Process .Bast  <-  3. Host; 

MB. Dest Process. Hast  <-  LocalHost; 
RecordHOLD\QX(MB) ; 

END; 
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Ir.putMcssCar.cel  <- 
EXPR(D: NetBuffer) 

BEGIN 

DECL  MB: Mess Block; 

MB  < 1 1 MessCar.celFornat ; 

Format  Error  (3,  MB)  =>  NOTHING; 

MB. Source Process. Ho st  <-  3. Bast; 

MB. Dest Process. Host  <-  LocalBost; 

' RscordMESSX CANCEL (MB); 

END; 

InputXmit  <- 
EXPR(B: NetBuffer) 

BEGIN 

DECL  MB: Mess  Block; 

MB  <| ! XmitFcnnat; 

FormatErrcr(B,  MB)  =>  NOTHING; 

MB.  Source  Process.  Host  <-  LocalHost; 

MB. Dest Process. Host  <-  B.Host; 

RecordXMIT(MB) ; 

END; 

InputAlarm  <- 

» 

! In put Alarm,  ir.  addition  to  the  usual  irput  functions: 

! produces  an  AlannHar.dle. 


EXPR(B:  NetBuffer) 

BEGIN 

DECL  AB:  AlarnBlock; 

AB<i!  AlarmFormat; 

Ler.gthError(B)  =>  ProtocoIError(B) ; 

EhcodeGer.ericClass(A3. Saurce Process. Generic Natne)  //> 

ProtocolError(B) ; 

EhcodeGer.ericCIass(AB.  Dest  Process.  Generic  Name)  i?> 

Protocol Error (B) ; 

AB. .Source Process. Host  <-  B.Host; 

AB.DestProcess.Host  <-  LocalHost; 

DECL  AH: AlarmHar.dle  LIKE 

Allocate( AlarnHandle,  AB)  /*  1 Implicit  Seize* ; 

AH.  Dest  Process.  Ir.car  nation  Local  Incarnation  => 

BEGIN 

Ser.dALA  RM\  RE  J ( AH , 

"Bad  incarnation  number  on  destination  process’1); 

Free(AH) ; 

END; 

EnQInputAlarm(AH); 

Free (AH); 

END; 
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InputAlarmOk  <- 
EXPR ( B: NetBuffer) 

begin 

DECL  ABrAlarrnBlcck; 

AB  <J  J Alar.mOkFornat ; 

Forma  tError(B,  AB)  =>  NOTHING; 

AB. Source Process .Host  <-  LocalHost; 
AB.Dest Process. Host  <-  3. Host; 
RecordALARM\o:<(AB); 

END; 


Ir.putAlarmRej  <- 
EXPR (B: NetBuffer) 

BEGIN 

DECL  AB:  Alarm  Block  ; 

AB<1|  AlarnRej Format; 
FormatError(3,  AB)  =>  NOTHING; 
AB.SourceProcess.Host  <-  LocalHost; 
AB.Dest Process. Ho st  <-  B.Host; 
RecordALARM\R£J(A3) ; 

END; 


InputCorr.C^er  <- 

i 


j 

! 

j 

! 

I 

» 


InputCor.r.Open,  ir.  addition  to  the  usual  ir.put  functions: 
produces  a Corn  Handle, 

converts  MSG  connection  types  to  internal  -r.es, 
verifies  connection  type  (ore  and  only  one), 
and  verifies  bytesize  range. 


' */ 


EXPR(B: NetBuffer) 
BEGIN 


5^piex»  feceive>  Server  Telnet,  User  Telnet  :BCX)L; 

DtCL  CB:  Conn  Block; 

CB  <||  Conn Open Format ; 

IXiplex  <-  | TypeXduplex; 

Send  <-  | TypeXser.d; 

Receive  <-  | TypeXreceive; 

Server Telr.et  <-  TypeXServerTELNET; 

UserTelr.et  <-  | TypeXUserTELNET; 

C.CornType  <- 
BEGIN 


UserTelr.et  =>  '’User TELNET”; 

ServerTelr.et  =>  "Server TELNET”; 

"Binary”; 

END; 

C. Conn Direct ion  <- 

C)  Send  =>  "Qjt” ; Receive  =>  "In”;  "InOut”  (]• 
Ler.gthError(B)  =>  Protocol  Error  (B); 

EncodeGer.er  icCl  ass(  CB . Sour ce  Process . Generic Name)  #> 
ProtocolError(B); 

EhcodeGenericClass(CB.DestProcess.GenericName)  0> 

ProtocolError(B); 


fr'  r.  ''t:r  i i':  i7-V 


kssr-.-" 
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CB.SoureeProcess  .Host  <-  B.Host; 

CB. Dest Process. Host  <-  Local Host; 

DECL  CH: Cor r Handle  SHARED 
AllocateC  Corn  Handle,  CB)  /*  'implicit  Seize’; 

CH.Dest  Process.  Ir  carnation  if  Local  Incarnation  => 

BEGIN 

SendCONN\REJ(CH,  . 

’’Bad  incarnation  r.unber  on  destination  process  ); 

Free(CH); 

END; 

[)  Duplex  =>  1;  0 (]  + [)  Send  =>  1;  0 (]  + 

[)  Receive  =>  1;  0 (]  + [)  Server Telnet  =>  1;  0 (]  ♦ 

[)  UserTelr.et  = > 1;  0 (]  //  1 => 

BEGIN 

SendCONN\REJ(CH,  "Invalid  connection  type”); 

Free(CH) ; 

END; 

CH.CornBytesize  GT  MaxrntmCor.r.Bytesize  - 
BEGIN 

SendCONN\R£J(CH,  "Invalid  connection  byte  size’’); 

Free(CH) ; 

END; 

EnQIr.putOper.Corr.(CH); 

Free(CH) ; 

END; 

In  put Corn Close  <- 
EXPR(B:  NetBuffer) 

BEGIN 

DECL  CB: Corn Block; 

CB  < 1 1 Cor.nCloseFormat ; 

Ler.gthErrorC  B)  =>  ProtocolError(B) ; 

Er.codeGerericClassCCB.  Source  Process.  Generic  Name)  //> 

Protocol Error ( B) ; 

ErcodeGer.ericClassC CB. Dest Process .Ger.ericName) 

ProtocolError(B) ; 

CB. Source Process . Host  <-  B.Bost; 

CB.DestProcess .Host  <-  LocalHost; 

DECL  CH: Conn Handle  LIKE 

AllocateC Conr.Har die,  CB)  /*  ’Implicit  Seize’; 

CH.  Dest  Process.  Incarnation  //  Local  Ir.carratior  => 

BEGIN 

SendCONNXREJCCH, 

"Bad  incarnation  number  on  destination  process"); 

Free(CH) ; 

END; 

EhQIn  put  Close  Conn  (CH) ; 

END; 
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InputGorr.Re  j <- 
EXFR(B: Net Buffer) 

BEGIN 

DECL  CB:  Cor.r.  Block ; 

CB  < S ! Conr.RejFormat ; 

Forma  tError(B,  CB)  =>  NOTHING; 

CB.ScurcePr0c3ss.H0st  <-  3. tost; 

CB.Dest Process. tost  <-  Localtost; 

RecordCONN\REJ(CB); 

END; 

FormatError  <- 

i 

! FormatError  verifies  lengths,  generic  codes  and  incarnation 
! nunbers. 

! 

* */ 

EXPR(B: NetBuffer , TB:Trar.sactior.  Block;  BOOL) 

BEGIN 

Ler.gthError(B)  =>  [)  ProtocolError( B) ; FALSE  (]; 
EhcodeGer.ericClass(T3.  SourceProcess  .Ger.ericName)  //> 

C)  ProtocolError(B) ; FALSE  (]; 

EhcodeGenericClass(T3. Dest Process. Ger.ericName)  //> 

[)  Protocol Error ( B) ; FALSE  (J; 

TB.  lest  Process.  Incarnation  //  Local  Ir.ca“v  tior.  =>  FALSE; 

END; 

Length Error  <- 

* 

! Length  Errors  result  from  discrepancies  between  the  official 
! count  sent  by  MSG  and  actual  data  parsed.  If  the  official 

! count  is  long  then  B.Scar.  will  be  less  than  B.Read.  If  it 

! is  short  B.Scar.  'will  be  greater  than  B.Read,  the  parsing 

! routines  advancing  B.Scar.  past  3. Read  without  reading. 

i 

1 */  EXPR(B: NetBuffer;  BOOL)  B.Scar  //  B.Read; 

FrotocolError  <- 

? 

! ProtocolError  arranges  the  sending  of  a PtclL  r item  based  on  the 

! NetBuffer  passed  to  it.’; 


^ rtr— fir  rfTrgWr.V. 
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! Protocol  output  rcutineo 


• . 

i 

Protocol Output  <- 

t 

! Prc-ocol  Output  wo  it  s ur.til  it  \ SIGN.,  .ed,  then  loops  through 

! its  delivery  queue,  removes  entries  ar.d  dispatches  to  the 

! appropriate  output  routine.  The  entries  are  then  dequeued. 

i 

» */ 

EXPR (Ego:  Server Handle) 

BEGIN 

DECL  B: NetBuffer  LIKE  AllocateNetBuffer( ) ; 

DECL  QEr.try : Transaction  Handle; 

Seize(Ego.DeliveryQ) ; 

REPEAT 

Null (Ego. Oil iveryO)  -> 

BEGIN 

Ego. Running  <~  FALSE; 

Release(Ego.DeliveryQ) ; 

WAIT ( { Ego.WakeUpSigr.al  }); 

Seize (Ego.  Delivery 3) ; 

END; 

BEGIN 

Null (Ego.  Del iveryQ)  =>  NOTHING; 

QEr.try  <-  Fror t( Ego.  Del iveryQ) ; 

DECL  IsSeized:B00L  LIKE  TestSeize(QEntry) ; 

Release (Ego.  Del iveryQ) ; 

NOT  Seized  => 

[)  Pause(  Seize  Wait ) ; Seize  (Ego. Deli*  eryQ)  (j; 
CASE[QEntry.  Pro  toco  1 Co  run  ar.d ] 

l "MESS"]  =>  OutputMess(QErtry , C); 

["MESS-OX"]  =>  OutputMessOkQEntry,  3); 

["MESS-REJ"]  =>  Output  Mess  Re  j ( QEr  try,  B); 

[” MESS-HOLD"]  =>  OutputMessHold(QEr.try,  B); 

["HOLD-OX"']  =>  Ou  tpu  t Hu  Id  Ok  ( QEr.  t r y , B); 

["MESS-CANCEL"]  =>  OutputMessCar.ceKQEntry,  B); 

L v*xt"]  OutputXmit  (QEr.try,  B); 

[ R‘T’]  =>  OutputAlarn(QEntry,  B); 

["Al.  4-OX"]  =>  Outpu tAlarrnOk( QEr.try , B); 

[”AL  1EJ"]  =>  OutputAlarnRej (QEr.try,  B); 
["CONN-OPEN"]  =>  Ou  tpu  t Conn  Oper  (QEr  try , B); 
["CONN-CLOSE"]  r>  Ou  tpu  tCor.n  C lo  se  ( QEn  t r y , B); 
["CONN-REJ"]  =>  OutputCor.r  Re  j (QEr.try,  B); 

["Start  ICP"],  ["Finish  ICP"]  => 

NewHost(  Release  (QEr.try) , B); 

TRUE  =>  MSG£rror( ’Bad  protocol  command*); 

END; 

QEn try. Protocol Comm and  = "Start  ICP"  OR 
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QEn  try.  Pro  toe  o 1 Gotlii  an  d = "Finish  ICP"  =>  NOTHIN 
i!  Header; 

' Length  <-  3. Scan; 

D£CL  HH: Ho st Handle  LIKE  SeizeHostCB. Host) ; 

B. Channel  <-  First(HH.Cnar.r.elS); 

NetSer.dltem(B)  //> 

BEGIN 

DECL  Local Socket: Socket  LIKE 
Ge t Soc k 3 1 F roii Channel (B. Cn ar.n e 1 ) ; 
CHCL0SE(3.Giarrel); 

Deass  igr.MSGOutputSocket(  Local  Socket) ; 
ReiioveCHH.  Channels,  D.  Channel ) ; 
Null(Hri.Cnarr.elS)  => 

BEGIN 

DECL  Res  tart:  Cor  tactHar.dle  LIKE 
Allocate(Cor.tactHar.dle) ; 
Seize(Ego.DeliveryQ) ; 

Restart. Protocol Goirnar.d  <-  "Start  ICP"; 
Restart* , Re noteHost  <-  HH ; 

ErQAtFror.t(  Ego.  Deli  very  Q,  Restart) ; 

Re lease ( Ego. De 1 iver yQ ) ; 

Release ( Restart ) ; 

Re lease (HH); 

END; 

Release(HH) ; 

END; 

Release(HH); 

QEr.try.  Protocol  Gonmand  <-  Null Protocol Command; 
Seize(Egc.DeliveryQ) ; 

DeQCEgo.DeliveryQ,  QEr.try); 

Free(QEntry) ; 

END; 

END; 

END; 
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The  fcllowirg  routines  corvert  ir.terral  data  structures  tc 
protocol  items  ar.d  determine  the  target  host. 


OatputMess  <- 

» 

! CtitputMass,  ir.  addition  to  the  usual  output  functions: 
! converts  t ha  NoQWait  field, 

! sets  the  FirstByte  field, 

! and  moves  the  message  text  from  the  Mess Handle  to  the 
! NetBjffer  (via  OutputMessText) . 

i 

' V 

EXPR  CM : Me  ss  Han  die.  3: Net Buffer  SHARED) 

BEGIN 

M !!>  Mess Format; 

! Conmar.d  <-  "MESS" ; 

! NoQNait  <-  NOT  M.QWait; 

! FirstByte  <-  3. Scar; 

B.Hast  <-  M. Dest Process. Hast ; 

QjtputMessTextCB,  MrO; 

END; 


(XitputMessOk  <- 

EXPR(M:MessHar.dle,  3:NecBuffer  SHARED) 
BEGIN 

M ! ! > MessGk Format ; 

! Command  <-  "MESS-OX"; 

B.Hast  <-  iM. Saurce Process. Host ; 
END; 

OutputMessRej  <- 

EXPR(M:MissHar.dle , B:Nec3uffer  SHARED) 
BEGIN 

M !!>  MessRej Format; 

! Command  <-  "MESS-REJ"; 

B.Host  <-  M. Source Process. Ho st; 
END; 

QjtputMessHold  <- 

EXPR ( M : Mess  Hand le , B:NetBuffer  SHARED) 
BEGIN 

M j | > Mes:  - Id  Format ; 

! Command  s-  "MESS-HOLD"; 

B.Hast  <-  M. Source Process. Host ; 
END; 
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OutputHoldCk  <- 

EXPR(M: Mess Hard le,  B:NetBuffer  SHARED) 
BEGIN 

M ! ! > HoldOkFormat ; 

! Co.nmard  <-  "HOLD-OX"; 

B.Host  <-  M.Dest Process.  Host; 

END; 

OutputMessCar.cel  <- 

EXPR(M:MessHar.dle , B:N»tBuffer  SHARED) 
BEGIN 

M !!>  MessCar.celFormat ; 

Command  <-  "MESS -CANCEL"; 

B.Host  <-  M. Dost Process . Most ; 

END; 

OutputXmit  <- 

E XPR ( M : Mess Hard 1 e , B:NetBuffer  SHARED) 
BEGIN 

M !!>  Xmit Format; 

Command  <-  "X?^lITfl ; 

B.Host  <-  M. Source Process. Host ; 

END; 

OutputAlarm  <- 

EXPR(A:  Alar.nHar.dle  f B:  Nat  Buffer  SHARED) 
BEGIN 

A !!>  AlannFor:n3t ; 
i Command  <-  "ALARM"; 

B.Host  <-  A. Dest Process .Host ; 

END; 

OutputAlannCk  <- 

EXPR( A : Alarm Handle , B:NetBuffer  SHARED) 
BEGIN 

A 1 1 > Alarm Ok Format; 

! Command  <-  "ALARM-OX"; 

B.Host  <-  A. Sour ce Process. Host ; 

END; 

OutputAlarmRej  <- 

EXPR(A:AlarnHardle,  B:NetBuffer  SHARED) 
BEGIN 

A 11>  AlannRejFornat ; 

! Cormiand  <-  "ALARM-REJ"; 

B.Host  <-  A. Source Process. Host; 

END; 
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OjtputCornCper.  <- 

t 

! OutputCor.r.Open , ir.  addition  to  the  usual^output  functions: 
! converts  internal  connection  types  to  MSG  ones. 

i 

» */ 

EXPR(C:CorrHar.dle,  B:NetBuffer  SHARED) 

BEGIN 

C > ConrOpen.Fonnat ; 

TypeXduplex  <- 

C.ConnType  = "Binary"  AND  C.CorrDirection  = "Ir.CUt"; 

J TypeXserd  <-  C. Corn  Direct ion  = "Cut"; 

| TypeXreceive  <-  “ .ConnDirectlor.  = "In"; 

• TypeX5erverTEt.NET  <-  C. Corn Type  = "ServerTELNET"; 

TypeXUserTELNET  <-  C.Cor.nType  = "UserTELNET"; 

| Command  <-  "CONN -OPEN"; 

B.Host  <-  C. Dest Process. Host ; 

END; 

OjtputCor.r.Ciose  <- 

EXPR ( C : Conn  Handle , BiNetBuffer  SHARED) 

BEGIN 

C !!>  Conn Close Format ; 

Command  <-  "CONN-CLOSE" ; 

B.Host  <-  C. Dest Process. Ha st; 

END; 

Output Corn  Re j <- 

EXPR (C: Conn Handle,  BiNetBuffer  SHARED) 

BEGIN 

C !!>  Cor.nRejFornat; 

! Command  <-  "CONN-REJ"; 

B.Host  <-  C. Dest Process. Host ; 

END; 
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i 


' ICP  routines 

t . 


f 


i 


Receive  ICP  request 

OPEN  ICP  CHANNEL 

GET  HOST  AND  SOCKET  FROM  CHANNEL  HANDLE 
AUTHENTICATE  — STOP  IF  FAILURE 
GET  LOCAL  SOCKET  FROM  SYSTEM 
SEND  LOCAL  SOCKET 
CLOSE  IIP  C HA  in  EL 

OPEN  REMOTE  CHANNEL (S)  ON  LOCAL  SOCKET 
RECEIVE  SYNCH 
SEND  SYNCH 
KILL  OLD  TRAFFIC 

Ser  ICP  request 

GET  LOCAL  SOCKET  FROM  SYSTEM 

OPEN  ICP  CHANNEL  CM  LOCAL  SOCKET  — STOP  IF  FAILURE 
(HANDLE  AUTHENTICATION) 

RECEIVE  REMOTE  SOCKET 
CLOSE  ICP  CHANNEL 

OPEN  REMOTE  CHANNEL(S)  ON  LOCAL  SOCKET 
SEND  SYNCH 
RECEIVE  SYNCH 
KILL  OLD  TRAFFIC’; 


ICRJar.dler  <- 
» 


! ICPHar.dler  is  the  main  routine  of  the  ICP  handling  path.  It 
! waits  until  another  entity  initiates  contact,  verifies  that 
entity  as  an  MSG,  establishes  the  remote  and  local  sockets  to 
! used  in  the  permanent  connection,  creates  host  and  servers 

if  nonexistent,  and  notifies  the  network  output  server  that  a 
j connection  should  be  opened. 

• »/ 

EXPRO 

REPEAT 

BEGIN 


DECL  ICPChar.nel : Channel  Handle  LIKE 
CHOPEN  ( Make  Id  ( 0 , 0,  ICPSocket) , ’’Out”,  ’’Binary”,  32) 

^ /*  'This  blocks  until  someone  connects 

DECL  RemoteHost : Host Code  LIKE 


Get  Ha  st  From  Channel  ( ICPChar.nel ) ; 

DECL  RemoteSocket: Socket  LIKE 
GetSocketFromChar.nel  ( ICPChar.nel ) ; 
Auther.ticate(RemoteHost , RemoteSocket)  ft> 
CHCLOSEC  ICPChar.nel); 
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DECL  LocalSocket.-Socket  LIKE  Assi^rMSGSocketC ) • 

SEND(LoculS:cket,  ICPCharrel);  U’ 

CHCLOSE(ICPChar.rel); 

DECL  Remotellardle  iBostHar.dle  LIKE 
SeizeBost(RanoteHost) ; 

Null (Remote Handle)  -> 

BEGIN 

RemoteHardle  <- 

Allocate(HostHor.dle)  /#  'implicit  seize' * 

Remote  Bar. d 1 e . Bo s t <-  RemoteBost;  * 

RsmoteHar.dle . Ir putSorver  <- 
Allocate Net Input Server ( RemoteBost ) ; 

RemoteHardle. Del i yeryServer  <- 
AllocateNetCXitputServer  ( RemoteBost ) ; 

END; 

DECL  Fir.  i sh  Cor  t ac  t : Cor. tac t Handle  LIKE 

Allocate(Cor.tactHar.dle) ; 

FirishCor.tact.  Remote Bast  <-  RemoteHar.dle; 

Fir.ishCor.tact . RemoteSocket  <- 

Remote Socket  +2  /*  'NewHost  uses  RemoteSocket  as  input  socket’; 

Fir.ishCortaet  .LocalSacket  <- 

FiM^r^n^  L2.  /*  'r,'ewtbst  uses  LvscalSccket+2  as  input  socket'; 

r lr.isnCor.  tact.  Pro  toco  1 Comm  and  <-  "Finish  ICP"; 

Deliver( Finish Contact,  RemoteHar.dle); 

Release(Fir.ishGontact) ; 

Release (Remote Handle ) ; 

END; 

END; 


Authenticate  <- 


AM^entT^te  V,erifi'23  th3t  t!'"3  3r'tity  initiating  ar.  ICP  is  indeed  an 
ms,'  , :n?CKS  tnat  ths  re™te  socket  used  in  the  ICP  is  a valid 
fco  socket  by  contacting  the  re-note  MSG  through  its  authentication 
socket  and  receiving  the  range  or  list  of  that  MSGs  sockets.’; 
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SeizeHostHar.dle  <- 

! SeizeHostHar.dle  is  called  fro.Ti  the  user  call  server.  It  rot 
! or.ly  seizes  tne  har.dle  of  the  host  code  passed  to  it,  but 

! also  initiates  cor.tact  with  chat  host  if  it  is  unknown. 

! If  the  host  is  row  the  routine  creates  host  and  servers  ar.d 

! notifies  the  network  output  server  that  a connection  should 

! be  opened. 

i 

» V 

EXPR(RemoteHost :HostCode;  HostHar.dle) 

BEGIN 

DECL  RemoteHar.dle  HlostHar.dle  LIKE  Seize  Host  (Re.ncteHost) ; 

NOT  Nul  1( Reno te Handle)  =>  RemoteHar.dle; 

Remote Handle  <- 

Allocate (Host Handle)  /*  ' implicit  seize’ ; 

RemoteHar die. Host  <-  RemoteHost; 

Remote  Handle.  Input  Server  <- 

A1 located?  t In putServer(RemoteHost) ; 

RemoteHar.dle.  Delivery  Server  <- 

AllocateNetOjtputServer(RemoteHost) ; 

DECL  StartCor.tact:  Contact  Har.dle  LIKE 
AllocateCOartactHar.dle) ; 

StartCor.tact.  Remote  Hast  <-  RemoteHar.dle; 

StartContact . Protocol  Co  am  and  <-  ’’Start  ICP”; 

Del iver(StartCor tact , RemoteHar.dle) ; 

ReleaseCStartContact) ; 

RemoteHar.dle; 

END; 


SeizeHost  <- 

t 

! SeizeHast  finds  (in  Hosts)  and  seizes  the  host  handle  of  the 
! host  code  passed  to  it.  If  no  handle  is  found,  a null  har.dle 

! is  returned. 

i 

• V 

EXPR (HC  :HostCode ; HcstHar.dle) 

FOREACH  HH  IN  H*  stS 

DO  HH.Host  = HC  =>  Seize(HH);  NullHostHar.dle  END; 
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Newlbst  <- 

i 

! NewHost  establishes  a permanent  correction  with  a remote  MSG. 

! It  is  called  from  Protocol Output.  If  the  desire  for  the 

! correction  began  locally  ar  ICP  request  is  maHe  or  the  renote 

i M3G.  Ihe  input  ar.d  output  corrections  are  opened  and 

i inserted  ir.  tne  proper  charnel  sets,  syrehror izatior 

• information  is  exchanged,  transactions  addressed  to  a prior 

i incarnation  of  the  remote  MSG  are  cancelled,  and  the  input 

t server  is  signalled  that  a new  connection  exists.  If  the 

! connections  car.r.ot  be  opened,  HostDead  action  is  performed. 

i 

' */ 

EXPR( Contact: Contact Handle,  B:NetBuffer ) 

BEGIN 

Contact .Protocol Command  = "Start  ICP"  -> 

RequestlCP(Cor.tact) ; 

Null (Renote Socket)  =>  hbstDied( Contact) ; 

DECL  InputChannel : Charnel Handle  LIKE 
C HO  P EN  ( Ma  ke  Id  ( Con tac  t . Remo  t e Ha  s t . s t , 

Contact. RemoteSocket  + 1, 

Contact. LocalSocket  + 2),  "In",  "Binary", 

8); 

Nul  1 ( In pu t Cham e 1 ) =>  BostDied(  Contact) , 

DECL  OutputChar.r.el  :CnarrelHur.dl3  LIKE 
CHO  PEN  (Make  Id  ( Contact . RemoteHost . Host , 

Contact. RemoteSocket , 

Contact. LocalSocket  + 3)»  "Gjt", 

"Binary",  8); 

NulKOutputChar.nel)  => 

[)  CHC  LOSE  (Input  Cham  el);  HostDied! Contact)  (]; 

Syn.chror.ize( Contact,  Ir.putChar.nel,  Cbtput Channel , B)  //> 

BEGIN 

CHCL0SE(  Ir.putChar.nel); 

CHCLOSE(OutputCharr.el) ; 

HostDied! Contact ) ; 

END; 

DECL  Remote  Hast : Best  Handle  LIKE 
Seize ( Contact. RemoteHost) ; 

Insert( Remote Host .Connections,  QjtputChannel) ; 

DECL  InputServer -.ServerHar  die  LIKE 
Sei  ze(  RemoteHost . Ir.putServer ) ; 

Insert( InputServer .Channels,  InputOiannel) ; 

Release(  Ir.putServer ) ; 

Release( RemoteHost) ; 

DECL  Q : Que  ue ( Tr  an  s ac  t i on  Hand 1 e ) LIKE 
RemoteHost . Del iveryServer . Deliver yQ; 

Seize(Q); 

Seize! Contact) ; 

DeQ(Q,  Contact); 

Free! Contact) ; 

FOREACH  T IN  Q 
D° 

DECL  D: UNION (ProcessName,  HostHandlf  ) LIKE 


.-p<-  . . ..  Sk  » . .... 


Abstract  Model  of  MSG 
Module  REMOTE 


165 


RemoteDest(T) ; 

D.  Host  = RemoteHost. Host  AND 
D.  Incarnation  ft  RemoteHost.  Incarnation  -> 

REPEAT 

DECL  Success  :BXL  LIKE 
BEGIN 

TestSeize(T)  =>  HostDeadTrar.saction(T) ; 

FALSE; 

END; 

Success  =>  NOTHING; 

Released) ; 

Pause(SeizeWait) ; 

Seize(Q); 

END; 

END; 

Released) ; 

SIGNAL(Ir.putServer . WakeUpSigral ) ; 

END; 

RequastICP  <- 

» 

! Requ2stICP,  called  from  NewHost , establishes  the  local  and 
! remote  sockets  to  be  used  in  a network  connection  with  a 

! remote  host  ir.  response  to  the  desire  of  a user  to  contact 

! a process  on  that  host.  Tne  remote  socket  is  obtained  from 

! the  TCP  handler  of  the  host.  If  the  host  is  down  the  remote 

! socket  is  left  null. 

? 

f*  */ 

EXPR(StartCor.tact:ContactHandle) 

BEGIN 

Star  tCor.  tact.  Local  Socket  <-  AssigrMSGSocketC ) ; 

DECL  ICPChar.nel : Channel  Randle  LIKE 
CHOPEN (Make Id (StartCor. tact. RemoteHost. Host,  ICPSocket, 
StartCor.tact  .LocalSocket) , "Ir.M, 

’’Binary'1,  32); 

Null  (ICPChar.nel)  =>  NOTHING; 

'Authenticatior.Handler  is  consulted  now  by  remote  MSG’; 
Abnormal  (RECEIVE  (StartCor.tact . RemoteSocket,  ICPChar.nel))  => 
NOTHING; 

CHCLOSE(  ICPChar.nel); 

END; 
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HostDiei  <- 


i 

j 

i 

i 

• 

i 


HostDied  clears  up  '^er,  a P^^^^iffrled  ar.d, 

inUffre  r Mother  S*s  to  the  dost,  transactor, 
addressed  to  it  are  cancelled. 


EXPH  (c : Cor.tactHar.dle) 

^ De as s i jr MSGSoc ke t ' ^° l.^rr e'lS ) ^ > NOTHING; 

NOT  NulKC.RamotartjSo.Oiarrel 
“^^^^^W^r^rver^liveryO; 

Seize(Q); 

FOREACH  T IN  q 
DO 

BEGIN  u^ort  ICP"  OR 

T-rSoSar.d  - "Finish  ICP”  => 

T'[fsS(T);  SfS  Free(T)  (3; 

RemoteDest(T) .Host  - C.Ra;noteBost.rtost  -> 

"kS  Success :BOOL  LIKE 

BESstScize(T)  -->  HostDeadTrar.sactior.CT) ; 

FALSE; 

SuSms  =>  O !*>«•  T):  Free(T) 

ReleaseCQ) ; 

Pause (Seize Wait) , 

Seize(Q) ; 

END; 

END; 

END; 

ReleaseCQ) ; 


END; 
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Re.noteDest  <- 


i 

i 


Remotest  returns  the  process  r.a'ne  of  the  process  to  which 
the  giver,  transaction  is  addressed.  The  name  contains  the 
host  and  incarnation  nimber. 


E XPR  ( T : Tr  ar.  s ac  t ion  Han  d 1 e ; Process  Name ) 

CASE[T.  ProtocolGsiiuandj 

["Start  ICP"] , ["Finish  ICP"]  =>  Nul 1 Process Name ; 
["MESS-OX"], 

["MESS-REJ"], 

["MESS-HOLD"], 

["XMIT"], 

[ "ALARM -OX" ] , 

[ "ALARM-RE J"]  =>  T. Saurce Process ; 

TRUE  =>  T. Dqsi Process ; 

END; 


Synchronize  <- 

* 

! Synchronize  exchanges  SYNCH  information  with  the  remote  MSG, 

! using  tre  charnels  opened  by  NewHost.  The  incarnation  nimber 

! of  the  remote  host  is  obtained  and  stored  in  its  host  handle. 

• */ 

EXPR(CH:Cor.tactHar.dle, 

IC: Channel Handle, 

OC:  Charnel  Handle, 

B: NetBuf fer ; 

BOOL) 

BEGIN 

DECL  Successful: BOOL; 

IS  Synch Format; 

B.Host  <-  CH.R2m0teH0st.H0st ; 

FOR  I TO  2 
REPEAT 
BEGIN 

CH.  Protocol Comm and  = "Start  ICP"  AND  I = 1 OR 
CH, Protocol  Command  = "Finish  ICP"  AND  I = 2 => 

BEGIN 

| Command  <-  "SYNCH"; 

I My  Incarnation  <-  MSGIncarr.ation; 

| Your In carnation  <- 

[)  I = 1 =>  0;  CH. RemoteHost. Incarnation  (]; 

! Version  <-  MSGVersion; 

I Length  <-  B.Scan; 

B. Channel  <-  0C; 

Successful  <-  NetSendltem(B) ; 

END; 

B. Channel  <-  IC  ; 

DECL  Result: Reason Code  LIKE  NetReCeiveltem(B) ; 

Successful  <- 

Result  //  "Normal"  OR  I Conmand  //  "SYNCH"  OR 
! Version  //  MSGVERSION  //>  NOTHING; 
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AuthenticationHandler  <- 

» 

! AuthenticationHandler  sen 

i infomiatior.  in  response 

i are  stimulated  by  Roques 


ds  out  MSG  socket  ver ificatior 
to  requests  for  it.  Such  reque 
■tlCP 


*/ 


EXPRO 

RES  Auther.tioatior.Giar.r.ol  iChar.r.elHa^l  MICK 

CHOPEU (M ak-2 1 J ( 0 , 0,  HUther.v-icatior.So 
"Out", 

"Binary" , 

R2) ; 

SEND(MSGSoi:«tRar.je,  Authentication  Channel) ; 
CHCLOSEC  Authentication  Cnarr.el) , 

END; 
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